On Mon, Jan 12, 2015 at 1:06 PM, Michael Catanzaro
<[email protected]> wrote:
I'm definitely interested in knowing which sites you've discovered
are broken with and without %LATEST_RECORD_VERSION in the priority
string, when -VERS-SSL3.0 is also present in the priority string. (I
don't really care what sites are broken by -VERS-SSL3.0, as it's not
reasonable to enable SSLv3 anymore and Firefox has already dropped it
as well.)
For what it's worth, it's come to my attention that by disabling SSLv3
we have broken our insecure TLS protocol version fallback. That might
be what's causing problems for you.
Normally when we connect to a server, we say "the highest protocol
version we support is TLS 1.2" then the server says "too bad, I only
support TLS 1.0" and makes a TLS 1.0 connection. 99% of servers on the
web will look at the protocol version we send, then make the connection
with the newest version supported by both client and server. But the 1%
of servers that are TLS version intolerant see a version they don't
recognize, have no clue what to do, and give up. When that happens, we
as a client then try again, pretending to only support a lower protocol
version. (This means the attacker can downgrade us to the lower version
trivially by blocking the first connection, which is the only reason
POODLE was so bad.) Firefox will try TLS 1.2, TLS 1.1, then TLS 1.0
(and previously SSL 3.0). We used to try TLS 1.2 and then SSL 3.0, but
now we actually tell GnuTLS to do a second connection with all protocol
versions disabled, so it doesn't work. This should be fixed in
glib-networking 2.44 (to be released next month, you can grab a 2.43
development snapshot if this is important to you) which is smart enough
to fall back to the oldest protocol version that we haven't disabled
(currently TLS 1.0), thanks to work by Dan Winship. (I'm still having
difficulty with one particular test site [1], but I think there is an
unrelated problem.)
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1177964
_______________________________________________
webkit-gtk mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-gtk
