Closed
Bug 1420302
Opened 8 years ago
Closed 8 years ago
reset connection on HTTPS site that only TLS v1.2
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: lilian.benoit, Unassigned)
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20170419042421
Steps to reproduce:
try to connect on HTTPS site that accept only TLS v1.2
Actual results:
Firefox show message : reset connection
Expected results:
page is displayed. Il's with Chrome and other navigator. I use ssllabs.com for test. show attachments
Site authorize tls 1.2 only.
| Reporter | ||
Comment 1•8 years ago
|
||
I add picture that show tls 1.2 is only authorized by server
| Reporter | ||
Comment 2•8 years ago
|
||
I verify with wireshark. I receive RST Packet after Client Hello.
I try force firefox to use TLS 1.2 only (security.tls.version.min=3)
I have same result. Page don't display.
Comment 3•8 years ago
|
||
This works for me with a site that supports only TLS1.2 : https://fancyssl.hboeck.de/
Important: You have to change your system time if you want to test because the certificate of that Domain is expired.
Reporter: Please provide an example URL.
Component: Untriaged → Security: PSM
Flags: needinfo?(lilian.benoit)
Product: Firefox → Core
| Reporter | ||
Comment 4•8 years ago
|
||
You can try on https://indicateurs-suivi-de-parcours.emploi.gouv.fr
| Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(lilian.benoit)
Comment 5•8 years ago
|
||
Thanks, I can confirm that only Firefox (Firefox5 -> Firefox nightly) seem to have a problem with that URL.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•8 years ago
|
||
After a ssllabs scan it seams right, that the connection to https://indicateurs-suivi-de-parcours.emploi.gouv.fr fails, but one can assume it should be with a "no-cipher-overlap" error.
https://fancyssl.hboeck.de/ use ciphers supported by Firefox.
Comment 7•8 years ago
|
||
This is working as intended (at least in the client). The server is sending a TCP RST, so Firefox says that the connection was reset.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
| Reporter | ||
Comment 8•8 years ago
|
||
I contacted network team of this site
Their IPS dropped packet because firefox use unauthorized cipher level.
This seems related to hash SHA
rule IPS has been deactivated for a moment and firefox connected with this CIPHER : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Firefox is unique browser to connect with this CIPHER (picture of SSLLabs.com)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
| Reporter | ||
Comment 9•8 years ago
|
||
Comment 10•8 years ago
|
||
> rule IPS has been deactivated for a moment and firefox connected with this CIPHER : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
This makes no sense. The server selects the cipher suite and the site replies with TCP RST to the client hello.
Comment 11•8 years ago
|
||
Oh I see what's happening here. I guess the TLS endpoint sits behind some interceptor that drops TLS connections with cipher suites it doesn't like. And in this case this interceptor wants to use only RSA (probably to inspect traffic as well). Firefox only supports a couple legacy RSA cipher suites, not TLS_RSA_WITH_AES_128_GCM_SHA256, which would be needed.
So the question is whether we should enable that cipher suite in Firefox. I'd say no as it's an RSA suite, but this might be worth discussing.
Flags: needinfo?(jjones)
Flags: needinfo?(dkeeler)
Comment 12•8 years ago
|
||
I think it's well established that Chrome supports TLS_RSA_WITH_AES_128_GCM_SHA256 and Firefox does not; I see that all over the web in searches. It seems like this provider is deliberately choosing to exclude Firefox users.
This would affect every recent version of Firefox, right? Like, all the way back to 2016?
Flags: needinfo?(jjones)
| Reporter | ||
Comment 13•8 years ago
|
||
@Mathias has tested from Firefox 5 to nightly build
Beyond chrome support, this problems is not (perhaps) link to SHA for message authentication algorithm instead SHA256 or SHA384 ?
Comment 14•8 years ago
|
||
Well, we already decided to not enable TLS_RSA_WITH_AES_128_GCM_SHA256 in bug 1029179. I suppose since SHA-1 is being deprecated, we might see more servers (and/or middleboxes as in this case) that refuse to have anything to do with SHA-1 (even though, as I understand it, the attacks against SHA-1 don't apply to its use in the HMAC in TLS 1.2). That said, Firefox does offer ciphersuites with SHA256/384 - they just happen to all also use forward-secret key-exchange.
All in all, until we have some indication that this is a widespread compatibility issue, and unless we can't convince sites to use more modern ciphersuites, I don't think we should include support for another legacy RSA key-exchange ciphersuite.
Flags: needinfo?(dkeeler)
Updated•8 years ago
|
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → WONTFIX
Comment 15•7 years ago
|
||
The problem is relevant at the moment. The problem with many sites using the SSL certificate (as an example, which often used by me - https://guidessimo.com/guides-type/telescope/). At the same time, the same websites are perfectly open in Opera and Chrome. Firefox show message : reset connection.
You need to log in
before you can comment on or make changes to this bug.
Description
•