Loading https://panel.dreamhost.com fails with "The connection was interrupted"

RESOLVED FIXED

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: cpeterson, Assigned: emk)

Tracking

({regression, reproducible})

unspecified
x86
All
regression, reproducible

Firefox Tracking Flags

(firefox33 unaffected, firefox34 unaffected, firefox35 unaffected, firefox36 verified)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

4 years ago
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

4 years ago
Perhaps bug 1088915?

Updated

4 years ago
Blocks: 1088915

Updated

4 years ago
Keywords: regressionwindow-wanted
OS: Mac OS X → All

Comment 2

4 years ago
I emailed DreamHost support to get their TLS act together. My tracking # there is 6550462.
(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

4 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

4 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

4 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

4 years ago
Created attachment 8516641 [details] [diff] [review]
Deal with "cipher mismatch intolerant" servers

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: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #8516641 - Flags: review?(dkeeler)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1092998
(Assignee)

Updated

4 years ago
Attachment #8516641 - Attachment description: Deal with "cipher mismatch intolerance" servers → Deal with "cipher mismatch intolerant" servers
Component: Networking: HTTP → Security: PSM
(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

4 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

4 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.
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

4 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

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox36: affected → verified
Resolution: --- → FIXED
(Assignee)

Comment 14

4 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

4 years ago
Component: Security: PSM → Desktop
Product: Core → Tech Evangelism

Comment 15

4 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?
You need to log in before you can comment on or make changes to this bug.