[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: Re?: How to make a secure tcp connection without using certificate
From:       Jakob Bohm <jb-openssl () wisemo ! com>
Date:       2014-05-30 20:00:03
Message-ID: 5388E343.1010008 () wisemo ! com
[Download RAW message or body]

On 5/30/2014 12:03 AM, Dave Thompson wrote:
>> From: owner-openssl-users@openssl.org On Behalf Of Jakob Bohm
>> Sent: Wednesday, May 28, 2014 13:04
>
>> On 5/25/2014 2:22 PM, Hanno Böck wrote:
>
>>> Some clients (e.g. all common browsers) do fallbacks that in fact
>>> can invalidate all improvements of later tls versions.
>>>
>>> These fallbacks also can happen by accident (e.g. bad connections) and
>>> sometimes disable features like SNI.
>>>
>>> That's why I recommend to everyone that we need at least to deprecate
>>> SSLv3.
>>>
>>
>>
>> There is also the very real issue that a few platforms which no longer
>> receive feature updates (such as new TLS protocol versions) are stuck
>> at SSLv3.  Permanently.  So until those platforms become truly extinct,
>> a lot of servers need to cater to their continued existence by allowing
>> ancient TLS versions.
>>
>> At that point the problem is how to do the best defense against
>> man-in-the-middle downgrade-to-SSLv3 attacks.  For instance is there a
>> way to
>> ensure that the server certificate validation done by an SSLv3
>> (compatible) client will fail if both server and client were capable of
>> TLS v1.0, but a man in the middle tampered with the version negotiation?
>>
> I don't think you want it on the cert.

Sorry for the sloppy wording, I obviously meant the certificate powered
validation of the handshake, not the certificate attributes.

>
> The Finished exchange protects against *tampering* in a handshake,
> and has since SSLv3 (inclusive). The problem is clients that fall back
> at the application level if the (good) handshake is *blocked* (denied).
> Remember we had a fair number of "legit" cases of this when TLSv1.2
> in 1.0.1 added numerous suites by default plus one extension and
> ClientHello growing beyond 256 broke some servers -- even though
> they claimed to implement specs that implicitly required it. In those cases
> it was actually reasonable for a client to fall back to 1.1.
>
>> Failing that, is this something that could be added to the TLS v1.3
>> standard (i.e. some signed portion of the SSLv3 exchange being
>> unnaturally different if the parties could and should have negotiated
>> something better).
>>
> I see no reason to tie this to a TLSv1.3 document, when and if there is one.
> This is a proposed change to SSL, which is not TLS (only technically similar).
> The "prohibition" on SSLv2 is a standalone document: 6176, which updates
> 2246 4346 5246 to retroactively remove the SSLv2 compatibility.
> (Of course an IETF prohibition has no legal force and doesn't actually
> prevent or even deter people from continuing to use SSLv2, it just lets us
> wag our fingers at them.) Since SSLv3 was belatedly retroactively published
> as 6101, this could even be labelled as an update to that, FWIW.
>
>> Not remembering the SSLv3 spec details, one option could be to announce
>> support for a special "we also support TLS v1.0" cipher suite, which no
>> one can really implement (by definition), but whose presence in a
>> cipher suite list from the other end indicates that said other end
>> announced SSLv3.1 (TLS v1.0) support in an unsigned part of the
>> exchange.  This could even be specified in an "UPDATE RFC" for the
>> existing TLS v1.0..v1.2 versions, and a CVE number assigned to the
>> common bug of its non-implementation (after library implementations
>> become available).
>>
> In other words like the Signaling CipherSuite Value (SCSV) used for
> 5746 Secure Renegotiation (aka the Apache bug) in cases where the
> extension didn't work (or might not work reliably). I'd say experience
> confirmed that worked well enough to be considered an option.
>
> But many users, especially web users, want to connect to the server
> even if it isn't "truly" secure. When we make it harder for https to
> work, they *will* use http instead, or else complain very loudly.
>

Indeed, that is why such TLSvX.Y SCSVs need to be carefully designed to
specify what each one claims other than simply "every (obscure or not)
aspect of some very long spec, which might have common  misimplementations".



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]