Closed
Bug 1092952
Opened 10 years ago
Closed 10 years ago
Loading https://panel.dreamhost.com fails with "The connection was interrupted"
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(firefox33 unaffected, firefox34 unaffected, firefox35 unaffected, firefox36 verified)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox33 | --- | unaffected |
firefox34 | --- | unaffected |
firefox35 | --- | unaffected |
firefox36 | --- | verified |
People
(Reporter: cpeterson, Assigned: emk)
References
Details
(Keywords: regression, reproducible)
Attachments
(1 obsolete file)
STR:
1. Try to load https://panel.dreamhost.com/
RESULT:
Error page: "The connection was interrupted. The connection to panel.dreamhost.com was interrupted while the page was loading."
I believe is a regression in Nightly 36 build 2014-11-01. I tried to bisect the regression further, but my test results are inconsistent.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6bd2071b373f&tochange=b695d9575654
Comment 1•10 years ago
|
||
Perhaps bug 1088915?
Updated•10 years ago
|
Keywords: regressionwindow-wanted
OS: Mac OS X → All
Comment 2•10 years ago
|
||
I emailed DreamHost support to get their TLS act together. My tracking # there is 6550462.
Comment 3•10 years ago
|
||
(In reply to Anne (:annevk) from comment #2)
> I emailed DreamHost support to get their TLS act together. My tracking #
> there is 6550462.
Thanks for doing that Anne. This is probably a combination of bug 1088915 AND bug 1084025. Though a compliant server will not trigger this behaviour. The problem here is that the logic in bug 1088915 looks for a very specific error code. That code is generated by a *compliant* server, but it seems like dreamhost aren't playing nice.
:emk, do you think that you could expand the list of reasons for dropping back to weak ciphers to catch this?
Flags: needinfo?(VYV03354)
Reporter | ||
Comment 4•10 years ago
|
||
Curiously, DreamHost's home page at https://www.dreamhost.com/ loads correctly (with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bits key, TLS 1.2).
Comment 5•10 years ago
|
||
DreamHost is in the progress of updating all their servers as far as I understand the situation (see http://www.dreamhoststatus.com/ under "Upgrading"), but they are taking rather long to get there.
So depending on how fast they get there, this might get resolved in time. (They have not yet replied to me by the way.) whatwg.org is another case of a DreamHost server that is not updated, but curiously SSLv3 is not disabled there and it offering both TLSv10 and SSLv3 combined with RC4 does not seem to trigger an issue in Firefox Nightly.
Assignee | ||
Comment 6•10 years ago
|
||
(In reply to Martin Thomson [:mt] from comment #3)
> Thanks for doing that Anne. This is probably a combination of bug 1088915
> AND bug 1084025. Though a compliant server will not trigger this behaviour.
> The problem here is that the logic in bug 1088915 looks for a very specific
> error code. That code is generated by a *compliant* server, but it seems
> like dreamhost aren't playing nice.
>
> :emk, do you think that you could expand the list of reasons for dropping
> back to weak ciphers to catch this?
Bug 1084025 was unrelated (see bug 1088915 comment #36).
I'm testing it locally and it looks like works. Patch is coming.
Flags: needinfo?(VYV03354)
Assignee | ||
Comment 7•10 years ago
|
||
Honestly, I'm reluctant to add this. They should really stop needing RC4 cipher suites especially when they are going to drop SSL 3.0 support...
Assignee | ||
Updated•10 years ago
|
Attachment #8516641 -
Attachment description: Deal with "cipher mismatch intolerance" servers → Deal with "cipher mismatch intolerant" servers
Updated•10 years ago
|
Component: Networking: HTTP → Security: PSM
Comment 9•10 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #7)
> Honestly, I'm reluctant to add this. They should really stop needing RC4
> cipher suites especially when they are going to drop SSL 3.0 support...
Yep. It's not great. But it's not practical to unilaterally turn the security up to the maximum. If that were the case, we'd be reduced to using 4096-bit ff-DHE and maybe ECDHE with SHA-256 certificates and AES-GCM on TLS 1.2 only. Of course, we could only talk to a handful of sites then. Then we would lose relevance because our users would just switch to our competitors.
As it stands, I think that we can strike a balance. If people want a tougher browser, maybe we can ship a "paranoid version" extension for them that disables all of the bad stuff.
Comment 10•10 years ago
|
||
We should start logging warnings to the console, e.g. bug 1092835 & co. And we should probably also actively measure usage. That will pave some path towards getting developers more informed about this going forward and making it easier to remove bad features.
Assignee | ||
Comment 11•10 years ago
|
||
(In reply to Martin Thomson [:mt] from comment #9)
> Yep. It's not great. But it's not practical to unilaterally turn the
> security up to the maximum.
I agree in general. But in this specific case, they break compatibility and kill WinXP/IE6 users without adding any security benefits. They don't allow CBC mode block ciphers anyway.
> If that were the case, we'd be reduced to using
> 4096-bit ff-DHE and maybe ECDHE with SHA-256 certificates and AES-GCM on TLS
> 1.2 only.
As an aside, we should support at least two methods in case the algorithm has a vulnerability or an NSA backdoor.
Comment 12•10 years ago
|
||
If you believe the research, AES-GCM is the only mode not broken or weakened somehow (see RFC 7366). They aren't *completely* broken, but that's not the point. We don't do this because we accept that some security for a large group is better than really good security for a vastly reduced group.
And yes, I take your point about vulnerability: currently we have only finite field DH if ECDH proves to be somehow bad. But we're working on that (or the CFRG are) and we should have new curves (in a twisted Edwards form, no less) relatively soon.
Comment 13•10 years ago
|
||
So far DreamHost told me that someone specific is looking into it and that therefore it might take a little longer to get a response. However, per https://www.ssllabs.com/ssltest/analyze.html?d=panel.dreamhost.com they are now offering more than RC4 and can therefore be accessed again. Not quite the upgrade we are looking for, but it works.
Reporter | ||
Updated•10 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 14•10 years ago
|
||
Comment on attachment 8516641 [details] [diff] [review]
Deal with "cipher mismatch intolerant" servers
Transferred to bug 1092998.
Attachment #8516641 -
Attachment is obsolete: true
Attachment #8516641 -
Flags: review?(dkeeler)
Assignee | ||
Updated•10 years ago
|
Component: Security: PSM → Desktop
Product: Core → Tech Evangelism
Comment 15•10 years ago
|
||
Did anyone ask DreamHost which kind of SSL server they were using on panel.dreamhost.com when only the RC4 cipher suites was enabled?
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•