[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240808205540.267A1153AD7@kent.sdaoden.eu>
Date: Thu, 08 Aug 2024 22:55:40 +0200
From: steffen <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: feedback requested regarding deprecation
of TLS 1.0/1.1
Steffen Nurpmeso wrote in
<20240808190532.Uwg8_Ylc@...ffen%sdaoden.eu>:
|Clemens Lang wrote in
| <E3810E68-25CC-456F-9DC4-A03752C43E79@...hat.com>:
||> On 7. Aug 2024, at 22:16, Steffen Nurpmeso <steffen@...oden.eu> wrote:
...
||> To reiterate that SSL/TLS are standards, they had version
||> iterations, which possibly got around some real protocol problem.
||> These offer standardized sets of ciphersuites, some of those, of
||> the elder versions, are "no longer secure". (I am no
...
||> as i understand it, even TLSv1 supported forward-secrecy stuff, ie
||>
||> # openssl ciphers -v EECDH+AESGCM:EECDH+AES256:CHACHA20:!DHE
||>
||> gives two members, and except for the SHA-1 MAC this looks pretty
||> modern. But again: i am far from being an expert.
||
||TLS < 1.2 only supports a single signature algorithm, which uses SHA1-MD5 \
||\
||as digest.
||Only TLS >= 1.2 supports the signature_algorithms extension to negotiate \
||modern digests.
||
||MD-5 is fully broken. SHA-1 is questionable. Their combination may \
||withstand attacks a little bit longer, but probably not by much.
||
||The MAC is actually fine, since it’s HMAC with SHA-1, which isn’t as \
||affected by a SHA-1 collision attack [1].
||
|| [1]: https://security.stackexchange.com/questions/187866/why-aren-t-coll\
|| \
|| isions-important-with-hmac
|
|Ok, here you got me. I would have to (actually a little bit of
|re-) read the entire TLS specification 1.1 (2246) in order to give
|some useful answer. Ie, whether the non-HMAC usage of MD5/SHA-1
|in TLSv1.1 is used in a way that is truly problematic, or whether
|they exist in data blocks that are protected by other means,
|protected by the stream cipher or signed by a key that anyway has
|to be verified via private/public key cryptography.
That is: whether "vulnerability" thus means to create a fake
packet with identical MD-5 and SHA-1 hashes (it seems TLSv1.1
always uses both concurrently, at least for RSA) as the
cryptographically verifiable one that ships with the packet.
It seems to me this is hard stuff, especially for "the occasional
attack". *But*, if the protocol is resistant against downgrading
it would be used only for those connections which cannot use
anything else.
The real question for me (who cannot help possible remote stations
that cannot do any better) is how applications can deal with being
specific. For example openssl-s_client(1) allows per-connection
cipher suite configuration, the MUA i maintain does so per
destination server if you want to, for example. The postfix MTA
supports policy maps for at least the client side like this
/etc/postfix/tls_policy:
example.edu none
example.mil may
example.gov encrypt protocols=TLSv1
example.com verify ciphers=high
This narrows the necessary case of less modern support down to
(possibly falsely announced) host names, or fixed IP numbers.
I, as a non-cryptographer, would wonder whether some of the cipher
suites that are by default possible do not impose greater risks
than that.
|I never read 5246, just downloaded it an hour ago to read the
|referenced appendix. (Not a network expert etc.)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
