If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Persona accepting invalid SSL certs for primary detection.



Cloud Services
Server: Identity
4 years ago
4 years ago


(Reporter: David Illsley, Assigned: francois)


Firefox Tracking Flags

(Not tracked)




4 years ago
A couple of hours ago I found that my (fallback hosted) persona account (david@illsley.org) wasn't working. After some debugging, I discovered that it's down to me co-hosting the test domain I was playing around with last year (i5y.org) with illsley.org

When you connect to https://illsley.org/.well-known/browserid in firefox you get a warning about both an expired cert and the name mismatching. Unfortunately, it appears that the prod persona code is ignoring those warnings. I've now been able to set a browserid file there which delegates that domain to eyedee.me using the expired cert for the wrong domain:

$ curl -vv -k  -3 https://illsley.org/.well-known/browserid
* About to connect() to illsley.org port 443 (#0)
*   Trying
* connected
* Connected to illsley.org ( port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* 	 subject: description=5sHVqRIlEOQv8gK4; C=GB; CN=www.i5y.org; emailAddress=davidillsley@gmail.com
* 	 start date: 2012-02-25 21:16:44 GMT
* 	 expire date: 2013-02-26 16:05:28 GMT
* 	 subjectAltName does not match illsley.org
> GET /.well-known/browserid HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
> Host: illsley.org
> Accept: */*
< HTTP/1.1 200 OK
< Date: Mon, 05 Aug 2013 19:36:33 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Last-Modified: Mon, 05 Aug 2013 18:53:47 GMT
< ETag: "4096a-1f-4e337d4151fd6"
< Accept-Ranges: bytes
< Content-Length: 31
< Content-Type: application/json
  "authority": "eyedee.me"
* Connection #0 to host illsley.org left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

davidillsley@Davids-MacBook-Air-2 ~
$ curl https://login.persona.org/wsapi/address_info?email=david%40illsley.org&issuer=default
[1] 34574

davidillsley@Davids-MacBook-Air-2 ~
$ {"auth":"https://eyedee.me/browserid/sign_in.html","prov":"https://eyedee.me/browserid/provision.html","type":"primary","issuer":"eyedee.me","normalizedEmail":"david@illsley.org","state":"transition_to_primary"}

(I'll change this just as soon as you've been able to confirm/refute the problem :)

Interestingly, the check_primary_support script doesn't accept illsley.org as a primary:

davidillsley@Davids-MacBook-Air-2 ~/Development/browserid/scripts
$ node check_primary_support illsley.org
info: process type is check_primary_support
debug: illsley.org is not a browserid primary: Error: CERT_HAS_EXPIRED
debug: illsley.org is not a browserid primary: Error: CERT_HAS_EXPIRED
error: illsley.org is not a browserid primary: Error: CERT_HAS_EXPIRED

Given that my david@illsley.org account has been working recently (I'd guess until about a month ago), I'd guess this is a change since then.

Let me know if you need any more information.



4 years ago
Assignee: nobody → gene

Comment 1

4 years ago
I've idenfified the cause of the problem and have deployed a new staging stack with a fix (I'll be detailing the fix shortly). jrgm was going to take a look at it in stage.

Comment 2

4 years ago
Staging looks good (says jrgm). Here's the fix : https://github.com/mozilla/identity-ops/commit/06cf56a2e6bf2652ce9a5e9b9548ff7e8b292231
Ever confirmed: true

Comment 3

4 years ago
I'm building new production stacks that incorporate this fix now and should have them out within the hour

Comment 4

4 years ago
I think once we fix this in prod, we'll want to open a bug in github on the browserid-server software since this vulnerability exists for installations not utilizing an outbound https proxy like we do.
Okay, new production stacks look ok. You can switch DNS (and cut it off on the old stacks).

Comment 6

4 years ago
This fixed code has been deployed live in production.

Comment 7

4 years ago
Fix looks good to me. In 4 hours? Good Work.

I've updated my server so it would no longer demonstrate the problem, so I've no objection to this bug being opened up at the appropriate time.


4 years ago
Assignee: gene → francois
David. A big thanks for reporting this to us!

Comment 9

4 years ago
I have submitted a pull request to set rejectUnauthorized to true everywhere in our codebase:


Given that this is fixed in production and that the pull request is public, I think we can uncloak this bug.

Comment 10

4 years ago
The pull request has been merged.
Last Resolved: 4 years ago
Resolution: --- → FIXED
un-hiding per :francois
Group: mozilla-services-security


4 years ago
Duplicate of this bug: 788896
You need to log in before you can comment on or make changes to this bug.