197670 - "http" displayed in keychain location when actually "https"

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: OS Integration, defect)

Description

[T. Chan]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6

When Camino adds a password to the keychain, the 'Where' field (reported by
Keychain Access) says 'https', even if the protocol used is http.

Reproducible: Always

Steps to Reproduce:
1. Access a (non-https) site that needs authenticaiton. Save the pass in the
keychain.
2. Open Keychain Access.
3. Find the password and look at the 'Where' field

Actual Results:  
It shows 'https' as the protocol, e.g. "https://192.168.0.3:80"

Expected Results:  
the actual protocol (http), e.g. "http://192.168.0.3:80"

It's no big deal, since it stores the port number anyway, except that it fails
to work with other browsers that save the correct protocol to the keychain (e.g.
it won't load the pass for the same site saved by Safari).

Comment 1

[Simon Fraser [no longer active]]

->pink

Comment 2

[Greg K.]

T. Chan, 20021104 is too old for bug reporting purposes. Please retest using a
current nightly build.

Comment 3

[Pete Doane]

confirmed with build 2003083002

Comment 4

[Josh Aas]

I cannot reproduce this bug with the 2003121803 nightly. I accessed a site
protected by .htaccess, non-https, entered the username/password and saved to
keychain. The protocol was correctly stored as http. Using Mac OS X 10.3.2.

Reporter - can you test to make sure this problem still exists for you and also
do a test or two to confirm that other browsers aren't experiencing the same
thing (i.e. make sure its not an OS bug)?

Comment 5

[T. Chan]

Confirmed present in Camino 0.7.
Confirmed not present in Safari whatever-version.

Weird in Camino 2003122103 (v0.7+):
It doesn't seem to ask me to enter credentials, instead only displaying the "Authorization Required" 
page (this is for both my router and Apache 2.0.48 on sodium), with both http and https.

Firebird doesn't use the keychain. I doubt Mozilla does either. Doubtful that the OS knows whether 
it's http or https.

Comment 6

[Mike Pinkerton (not reading bugmail)]

T.Chan, delete the file

~/Library/Application Support/Chimera/Application.regs

and try again. This is something that got wonked in the nightlies and trashing
this file will fix your inability to authorize.

please re-test or i'll mark worksforme based on josh's comments.

Comment 7

[T. Chan]

Now http produces the correct "where" in the keychain (http://192.168.0.4). This bit is fixed.

However, https produces an incorrect "where" in the keychain ("http://192.168.0.4:443" as 
opposed to "http://192.168.0.4"). This is broken (and it wasn't before, IIRC).

Using latest nightly (2004012703).

Comment 8

[Mike Pinkerton (not reading bugmail)]

yeah, safari displays https, we only display http. *shrug* it still works, not
sure this is that big of a deal

Comment 9

[T. Chan]

It is, nevertheless, a bug, since the protocol is https, and 443 is the default port so should not be 
specified (in compliance with safari).

Though unlikely, it's possible to serve both http and https on port 443. It also misses the entire 
point of identifying the protocol if putting in the wrong protocol is acceptable behaviour.

Comment 10

[Josh Aas]

keychain work -> 1.0

Comment 11

[Samuel Sidler (old account; do not CC)]

Updating summary to reflect actual bug as well as confirming with 2005072608.

Basically, we're showing http://192.168.0.1:443 instead of https://192.168.0.1
in the keychain when saving a password.

This is a minor bug, but a bug nonetheless. If it's non-trivial to fix, I say
move off 1.0 since the passwords are still saved and work correctly.

Thoughts?

Comment 12

[Stuart Morgan]

I'll likely fix this when I fix bug 202337

Comment 13

[T. Chan]

(In reply to comment #11)
> Basically, we're showing http://192.168.0.1:443 instead of https://192.168.0.1
> ... This is a minor bug, but a bug nonetheless.

It's a security hole. If you enter a password for an https site and store it in the keychain, you expect that it will only be sent if the site is https (and passes the relevant certificate checks).

Under the current protocol, I believe we send it over http on port 443 (unverified), which allows for a man-in-the-middle attack.

(Not that I have great faith in the default trusted CA's, mind you.)

Comment 14

[Stuart Morgan]

(In reply to comment #13)
> It's a security hole. If you enter a password for an https site and store it in
> the keychain, you expect that it will only be sent if the site is https (and
> passes the relevant certificate checks).

Have you actually verified that if you store something for https authorization it is auto-submitted when visiting the http version of the site?

> Under the current protocol, I believe we send it over http on port 443
> (unverified), which allows for a man-in-the-middle attack.

I'm not sure why you believe that, since the keys under which Camino stores credentials in the keychain have absolutely no bearing on the actual submission of authorization credentials to sites.  If what you say is true, then every wallet/satchel/keychain-based authentication done by any Mozilla product to an https URI is done in an unsecure manner, which I find wildly unlikely.

Please either do testing or look at the code before claiming that this is a security issue.

Comment 15

[Stuart Morgan]

This is partially fixed by bug 202337. It should work correctly for web forms, but unfortunately I couldn't find any way to get the information we needed from Gecko for HTTP auth. Right now we'll just guess based on the port in that case, but that's not a good solution long-term.

Comment 16

[Stuart Morgan]

It looked like nsIAuthPropmt2 would give us scheme information, so pushing to 2.0