Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No able to verify the key #11

Closed
eric1357a opened this issue Oct 4, 2016 · 15 comments
Closed

No able to verify the key #11

eric1357a opened this issue Oct 4, 2016 · 15 comments

Comments

@eric1357a
Copy link

After I decrypt the link from the email provided by encrypted.asc
The api reply with "Invalid request!"

@jimc-leones
Copy link

Mee2! I've attached the decrypted body,
which Mailvelope didn't decrypt (even though it decrypts other test messages encrypted
itself with this key). The mail reader is Roundcube (roundcubemail-1.1.5-9.1.noarch from
OpenSuSE). gpg decrypted the body with no hassle. I extracted the pieces of the
response URL into an editor window and pasted the result (minus line breaks) into Firefox,
plus other attempts e.g. using W3M; the server responded "invalid request" each time
(which is no lie).

Brainwave: there are an awful lot of 3D digraphs including one in the key ID which is
not authentic. And in fact, wherever '=' appears legitimately (not including line breaks),
it is followed by 3D, as if you were trying to URL-encode the '=' which should have been
changed to '%3D'. When I changed '=3D' wherever occurring to plain '=' the server
responded "Email address successfully verified!"

Also I think 'ampersand' needs to be URL-encoded or written as 'ampersand amp semicolon'.
(& let's see if the entity is shown.) But I've never had the validator barf on equal signs.
I've never attempted using '=\n' as an escaped line break; does that really work?

Attachment link for the decrypted body:
encrypted.txt

I'm assuming that the nonce includes a date and won't last forever, and the most a
hacker could do with it is re-verify my key which is already verified.

@toberndo
Copy link
Member

toberndo commented Nov 3, 2016

Brainwave: there are an awful lot of 3D digraphs including one in the key ID which is
not authentic. And in fact, wherever '=' appears legitimately (not including line breaks),
it is followed by 3D, as if you were trying to URL-encode the '=' which should have been
changed to '%3D'. When I changed '=3D' wherever occurring to plain '=' the server
responded "Email address successfully verified!"

Also I think 'ampersand' needs to be URL-encoded or written as 'ampersand amp semicolon'.
(& let's see if the entity is shown.) But I've never had the validator barf on equal signs.
I've never attempted using '=\n' as an escaped line break; does that really work?

The encoding used is quoted-printable. You can decode for example here: http://www.webatic.com/run/convert/qp.php

I think we should use UTF8 encoding instead to better support manual decryption with GPG for the verification emails.

@toberndo
Copy link
Member

toberndo commented Nov 3, 2016

Here is some info regarding the verification procedure:

If a key is uploaded, it is in a pending verification state. As long as it is not verified, all subsequent uploads of the same key will trigger new verification emails. Only the latest verification emails are valid and previous verification emails will be invalidated by a new key upload. A key in pending verification state can be overwritten by uploading the same key to the server multiple times, but also by uploading a different (maybe newly generated key) with the same email address as the previously uploaded key.

Once a key is verified (with at least one email address), a subsequent upload of the same key or of a key with identical email address will fail. That means for key update on the key server (e.g. after having changed the key by adding another email address) the key first has to be removed and only after confirming the key removal email from the server, another upload is possible.

The key server will send out verification emails for all email addresses attached to a key. Lookup by email address will only succeed for emails that have been verified. You can choose to not verify all emails on the key in order to prevent that a key can be found by a certain email address. But the key server does not strip UserIDs from the key which are not verified, that means a successful lookup will always return the complete key as it was initially uploaded.

For key upload, lookup and removal: https://keys.mailvelope.com/demo.html
Please check also Spam folder for possible verification emails.

Email verification emails are sent out encrypted in order to not only verify that the user has access to the email account but also that they are in possession of the private key of the key that was uploaded to the key server. Verification emails are in PGP/MIME format. Should your webmail or other PGP-enabled mail client not be able to decrypt the email correctly the following workaround can be applied: download the encrypted.asc file attached to the verification email, open in text editor, copy the armored text and paste into email that you send to yourself. Use Mailvelope to decrypt the email and click on verification link.

Errors from the server:

  • User id not found. If this error occurs when clicking on a verification link then it could either mean that this email is already verified on the server. Or that the verification link is outdated.
  • Invalid request. This occurs with malformed URLs. If you decrypt e.g. the verification email with GPG then the URL will be malformed due to the quoted-printable format. A work around as described above is to send yourself the armored PGP message of the verification email, decrypt with Mailvelope and click on the link. A second workaround is to decode the URL either with a service like http://www.webatic.com/run/convert/qp.php (be aware that you share the verification link with this service and potentially they could use the verification link, which should not be problematic if you plan to use the link for activation anyway):
    • open http://www.webatic.com/run/convert/qp.php
    • paste complete decrypted verification email in "Decode" field. If you paste only URL ensure to not modify the line breaks.
    • click "Decode"
    • copy URL from "Decoded" field

@S3TH76
Copy link

S3TH76 commented Nov 3, 2016

The URL link from decripted file it gives me an error - "Invalid request.", when I access it.

@toberndo
Copy link
Member

toberndo commented Nov 3, 2016

@S3TH76 I updated #11 (comment) with explanations of error codes from the server.

@S3TH76
Copy link

S3TH76 commented Nov 3, 2016

You don't understand! I followed all steps correctly, until the phase where after I received the encrypted file and decrypt it with mailvelope add-on from Mozilla Firefox.
When I access the url from decripted file for confirmation, I get an error message: "Invalid request!"

I'm curious if this service even function correctly....

invalid_request-mailvelope

I let it the tray to see browser, OS, time and file that was decrypted.

@eric1357a
Copy link
Author

http://www.webatic.com/run/convert/qp.php
Just decode your url with that website and it will be fine.
Just tested a minute ago

@S3TH76
Copy link

S3TH76 commented Nov 3, 2016

nope! Still Invalid request. I attach the image with new decoded from quote-printable in UTF-8.
Observe that '3D' doesn't exist anymore after '=' !
invalid_request-mailvelope-2

@toberndo
Copy link
Member

toberndo commented Nov 3, 2016

@S3TH76 @eric1357a Problem is that line breaks in the URL must not be modified before decoding. I updated #11 (comment) once again.

@eric1357a
Copy link
Author

@toberndo I know and I already finish verification

@stonemirror
Copy link

Yeah, I ran into this issue as well. When the attachment is decrypted — I did this manually, GPGTools isn't working on macOS Sierra yet — it looks like this:

Content-Type: multipart/alternative;
 boundary="----sinikael-?=_1-14802753242610.15335576003417373"

------sinikael-?=_1-14802753242610.15335576003417373
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hello David Schlesinger,

please click here to verify your key:

https://keys.mailvelope.com/api/v1/key?op=3Dverify&keyId=3Daa42caa60faf27f1=
&nonce=3DNONCEWENTHERE
------sinikael-?=_1-14802753242610.15335576003417373
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<p>Hello David Schlesinger,</p><p>please <a href=3D"https://keys.mailvelope=
.com/api/v1/key?op=3Dverify&keyId=3Daa42caa60faf27f1&nonce=3DNONCEWENTHERE">click here to verify</a> your key.=
</p>
------sinikael-?=_1-14802753242610.15335576003417373--

So, I've got a URL of

keys.mailvelope.com/api/v1/key?op=3Dverify&keyId=3Daa42caa60faf27f1=
&nonce=3DNONCEWENTHERE

Note that in addition to the three errant instances of "3D", there's also an errant equal sign between the keyID value and the ampersand preceding the nonce keyword (which Markdown doesn't seem to want to allow me to make bold or italic or something...)

Took me a few minutes to sort this out, but the correct URL ends up being:

keys.mailvelope.com/api/v1/key?op=verify&keyId=aa42caa60faf27f1
&nonce=NONCEWENTHERE

@shuffle2
Copy link

There is nothing wrong with this output, the message is just encoded for email.
You can decode it with this:

import email, sys

with open(sys.argv[1]) as f:
        m = email.message_from_string(f.read())
        if m.is_multipart():
                for p in m.get_payload():
                        print(p.get_payload(decode = True).decode('utf8'))
        else:
                print(m.get_payload(decode = True).decode('utf8'))

This is not a valid issue :p

@user-name-is-taken
Copy link

Not a developer on this project, just a user. When I tried to verify my key, the verification window appeared blank. Then I re-sized the window and everything appeared. Hope this helps.

@Undigon
Copy link

Undigon commented Apr 29, 2018

I ran into the same issue. I solved it using the online qp converter. I don't find it a satisfactory solution. This should not be an issue if the goal is to be "secure, easy" and "just as painless as modern messengers".

@toberndo
Copy link
Member

Verification emails use now PGP/Inline with plaintext, therefore encoding issues of that kind should not arise anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants