Closed Bug 1410406 Opened 7 years ago Closed 7 years ago

Firefox Sync uses IP address instead of domain name when syncing

Categories

(Firefox for Android Graveyard :: Android Sync, defect)

Firefox 56
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 765064

People

(Reporter: chris, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171003101214

Steps to reproduce:

 * Set up a self-hosted FF sync 1.5 instance.
 * Put it behind SSL.
 * Have it hosted on the same machine as other SSL sites.
 * When you request the IP address of the machine with multiple SSL sites hosted observe that it will return the SSL certificate of the first site who's SSL cert is loaded (apache2 behaviour).
 * When you run the Sync manually from Android's accounts list it instantly stops and says "never sync'ed".


Actual results:

Output from adb logat:

10-20 20:59:16.669 27926 27991 E FxAccounts: javax.net.ssl.SSLException: hostname in certificate didn't match: <CORRECT-HOSTNAME> != <DEFAULT-HOSTNAME> OR <DEFAULT-HOSTNAME>

So FF Sync process is saying that it is getting the SSL cert for DEAFULT-HOSTNAME when it expects the SSL cert for CORRECT-HOSTNAME (i.e. the ffsync server). What appears to be happening here is the Sync process is requesting the IP address e.g. https://IP-ADDRESS/... instead of the hostname e.g. https://CORRECT-HOSTNAME/ and it is getting back the default SSL cert rather than the correct one for CORRECT-HOSTNAME. I verified this by changing the first site and I observed that DEFAULT-HOSTNAME reported in the error message above changed to the new default site (which is still incorrect as FF Sync should be asking for CORRECT-HOSTNAME).

Hopefully that makes sense.

This behaviour started after I switched from a wildcard cert (where all the domains on the machine had the same SSL cert) to Let's Encrypt certs which are different for each domain on the machine.


Expected results:

FF Sync should function without errors.
This may be an issue with the client not supporting SNI.

Are recent builds of Firefox for Android using a current version of of the HTTPClient libraries?

https://stackoverflow.com/a/34449105
https://issues.apache.org/jira/browse/HTTPCLIENT-1119
Further data point: when I moved my sync server to be the first SSL virtualhost that is loaded FF Sync immediately started working. Upgrading Apache HttpClient to one after 4.3.2 should fix this issue and I'm happy to test a release incorporating such a fix against the breaking conditions above.
(In reply to chris@mccormick.cx from comment #1)
> This may be an issue with the client not supporting SNI.

Correct: https://bugzilla.mozilla.org/show_bug.cgi?id=765064.

> Are recent builds of Firefox for Android using a current version of of the
> HTTPClient libraries?

No.  What we want to do is stop using HTTPClient (and instead use Android's URLConnection (memory is fuzzy)), but it's work with risk for very little gain.  And now I can't find a ticket tracking this -- grisha, do you have one filed?
Flags: needinfo?(gkruglov)
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(gkruglov)
See Also: → 1412650
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.