I'm in my phone but rfc 2246 says that there are many ways in which an attacker can attempt to make an attacker drop down to the least secure option they both support. It's like the second or third paragraph of that section.
> On Nov 22, 2014, at 4:00 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > >> On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote: >> Yes this. SSLv3 isn’t a “Well as long as you have newer things >> enabled it’s fine” it’s a “If you have this enabled at all it’s a >> problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM >> who is willing to do active attacks can force the connection over >> to the lowest protocol that a client and server support. There is >> no way for the server to verify that the message sent from the >> client that indicates their highest was not modified in transit. > > IETF RFC 2246 disagrees with you on this. Please cite sources > (besides interactions with Web browsers that sidestep TLS version > negotiation a la POODLE). You're suggesting a vulnerability far > worse than e.g. CVE-2014-3511 in OpenSSL, which would definitely be > something I haven't seen disclosed to date. It's very easy to fall > into the protocol shaming trap, and I don't think it's at all > helpful. > -- > Jeremy Stanley > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
