Subject: [openpgp] Enigmail XSA issue with WKD and HTTP authentication

From: Hanno Böck <[email-masked]>
Date: Fri, 7 Dec 2018 15:44:41 +0100

Cross-posting this here as I believe this is something that should be
clarified in the WKD draft/standard.

There's an issue in Enigmail that can potentially be abused for
phishing attacks involving WKD and HTTP authentication.

Web Key Directory or WKD [1] is a feature where OpenPGP keys can be
fetched via a defined web address of the form
https://example.org/.well-known/./openpgpkey/hu/[zbase32_sha1_hash_of_local_part]

Enigmail automatically tries to fetch WKD keys already when writing a
mail, so simply having a mail address in "To" will cause an HTTPS
request.

When the server answers with a HTTP authentication challenge (HTTP code
401) then Enigmail/Thunderbird would open up an HTTP login window.
While the login window will show the hostname, this can be very
confusing for a user. If randomly a login window pops up within a mail
client it's plausible that some users will enter their email
credentials. Here's a video to illustrate the issue:
https://www.youtube.com/watch?v=eFSMBX98XiE

Similar attacks in browsers have previously been described as
"Cross-Site-Authentication" or XSA [2].

I think it would be good if the WKD draft would be updated to clarify
that a client should never answer to any 401 authentication requests
from the server.

I discovered this together with Moritz Tremmel (We discovered this by
accident due to a server serving HTTP authentication requests for
every path starting with a dot). After we reported this to Enigmail we
learned that this was previously reported in the public bug tracker:
https://sourceforge.net/p/enigmail/bugs/890/

[1] https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07
[2]
http://www.joachim-breitner.de/blog/56-Like_XSS,_just_simpler_and_harder_to_prevent__The_Cross_Site_Auth_(XSA)_Attack

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Werner Koch <[email-masked]>
Date: Fri, 14 Dec 2018 10:02:46 +0100

> that a client should never answer to any 401 authentication requests

Is this okay:

  A client MUST not accept a HTTP authentication challenge (HTTP code
  401) because the information in the Web Key Directory is public and
  needs no authentication.  Allowing an authentication challenge has the
  problem to easily confuse a user with a password prompt and tricking
  him into falsely entering the passphrase used to protect his private
  key or to login to his mail provider.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Hanno Böck <[email-masked]>
Date: Fri, 14 Dec 2018 11:06:59 +0100

On Fri, 14 Dec 2018 10:02:46 +0100
Werner Koch <[email-masked]> wrote:

>   needs no authentication.  Allowing an authentication challenge has
> the problem to easily confuse a user with a password prompt and
> tricking him into falsely entering the passphrase used to protect his
> private key or to login to his mail provider.

Sounds good.

-- 
Hanno Böck
https://hboeck.de/

---

From: Derek Atkins <[email-masked]>
Date: Fri, 14 Dec 2018 09:12:33 -0500

>   A client MUST not accept a HTTP authentication challenge (HTTP code

You should capitalize this as "MUST NOT" (and not "MUST not").

>   key or to login to his mail provider.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Werner Koch <[email-masked]>
Date: Fri, 14 Dec 2018 17:40:43 +0100

> You should capitalize this as "MUST NOT" (and not "MUST not").

Right.  I always have to fix up these.

Salam-Shalom,

   Werner

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 14 Dec 2018 17:59:52 -0500

>   key or to login to his mail provider.

The explanation and justification part here is very clear, and i agree
it should be included.  But is "accept an HTTP authentication challenge"
the same thing as "make an HTTP authentication prompt visible to the
user" ?

how about something more like "a WKD client MUST treat an HTTP response
code 401 the same way it treats a 404…"

   --dkg