Hello guys, I'm planning to release the "tls" package v2.0.0 probably within one month. It removes TLS 1.0/1.1 and provides only TLS 1.2/1.3 with safe cipher suites according to recent RFCs and internet-drafts. This version does not change the default usage. But if you are using custom parameters, you might have to modify your code. This breaking change is *intentional* to notice users that they are using vulnerable versions and/or parameters. The attached is the current change log. --Kazu ## Version 2.0.0 * `tls` now only supports TLS 1.2 and TLS 1.3 with safe cipher suites. * Security: BREAKING CHANGE: TLS 1.0 and TLS 1.1 are removed. * Security: BREAKING CHANGE: all CBC cipher suite are removed. * Security: BREAKING CHANGE: RC4 and 3DES are removed. * Security: BREAKING CHANGE: DSS(digital signature standard) is removed. * Security: BREAKING CHANGE: TLS 1.2 servers require EMS(extended master secret) by default. * BREAKING CHANGE: the package is now complied with `Strict` and `StrictData`. * BREAKING CHANGE: Many data structures are re-defined with `PatternSynonyms` for extensibility. * BREAKING CHANGE: the structure of `SessionManager` is changed to support session tickets. * API: `handshake` can receive an alert of client authentication failure for TLS 1.3 [#463](https://github.com/haskell-tls/hs-tls/pull/463) * API: `bye` can receive NewSessionTicket for TLS 1.3 * Channel binding: `getFinished` and `getPeerFinished` are deprecated. Use `getTLSUnique` instead. * Channel binding: `getTLSExporter` and `getTLSServerEndPoint` are provided. [#462](https://github.com/haskell-tls/hs-tls/pull/462) * Refactoring: the monolithic `handshake` is divided to follow the diagram of TLS 1.2 and 1.3 for readability. * Refactoring: test cases are refactored for maintenability and readablity. `hspec` is used instead of `tasty`. * Code format: `fourmolu` is used as an official formatter.
On Fri, Jan 19, 2024 at 10:21:56AM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote:
I'm planning to release the "tls" package v2.0.0 probably within one month. It removes TLS 1.0/1.1 and provides only TLS 1.2/1.3 with safe cipher suites according to recent RFCs and internet-drafts.
This version does not change the default usage. But if you are using custom parameters, you might have to modify your code. This breaking change is *intentional* to notice users that they are using vulnerable versions and/or parameters.
I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any chance you could find some way to explicitly keep these protocol versions enabled? -- Viktor.
On 19.01.24 02:51, Viktor Dukhovni wrote:
I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any chance you could find some way to explicitly keep these protocol versions enabled?
Could you switch to unencrypted connections? As far as my current knowledge goes, 1.x TLS isn't significantly safer than unencrypted anyway. Your other option would be to stick with the older tls library. If your code is again library code for consumption in other people's projects, you should consider retracting it, as it is (and in fact has been) undermining communication security for years. Regards, Jo
On Fri, Jan 19, 2024 at 08:19:06AM +0100, Jo Durchholz wrote:
On 19.01.24 02:51, Viktor Dukhovni wrote:
I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any chance you could find some way to explicitly keep these protocol versions enabled?
Could you switch to unencrypted connections?
In fact, no.
As far as my current knowledge goes, 1.x TLS isn't significantly safer than unencrypted anyway.
That's far from accurate. TLS 1.0, though dated, is quite adequate for many non-browser applications. -- Viktor.
On 19.01.24 09:17, Viktor Dukhovni wrote:
On Fri, Jan 19, 2024 at 08:19:06AM +0100, Jo Durchholz wrote:
On 19.01.24 02:51, Viktor Dukhovni wrote:
I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any chance you could find some way to explicitly keep these protocol versions enabled?
Could you switch to unencrypted connections?
In fact, no.
What's holding you back?
As far as my current knowledge goes, 1.x TLS isn't significantly safer than unencrypted anyway.
That's far from accurate. TLS 1.0, though dated, is quite adequate for many non-browser applications.
Well... sort-of. It depends on SHA-1 for initial handshake and peer authentication (both relevant to prevent man-in-the-middle attacks), and the best known algorithms to break it still require ~100 GPU years of compute power. However, there's that risk that some improved algorithm takes this attack vector from "merely feasible" to "routine". This could happen any day, or may already have happened but is being kept secret. I don't know if this is a relevant concern for the data you're dealing with. You'll have to think about the consequences if that data is decrypted or manipulated. BTW validating that a concern does not apply is more work than simply upgrading, in the vast majority of cases. Regards, Jo
On Fri, Jan 19, 2024 at 10:55:15AM +0100, Jo Durchholz wrote:
That's far from accurate. TLS 1.0, though dated, is quite adequate for many non-browser applications.
Well... sort-of. It depends on SHA-1 for initial handshake and peer authentication (both relevant to prevent man-in-the-middle attacks),
Actually, the TLS 1.0 hash algorithm used in digital signatures is SHA1+MD5, and there are no known practical attacks on that construction. https://datatracker.ietf.org/doc/html/rfc2246#section-7.4.3 select (SignatureAlgorithm) { case anonymous: struct { }; case rsa: digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }; case dsa: digitally-signed struct { opaque sha_hash[20]; }; } Signature; There are some theoretical attacks on concatenated hashes that suggest they're not quite as strong as one might naïvely hope, but this has little practical impact. The TLS 1.0 bulk ciphers use SHA1-HMAC (not raw SHA1): https://datatracker.ietf.org/doc/html/rfc2246#section-6.2.3.1 There are no known practical attacks on HMAC. In the browser context, there have been some practical attacks on CBC mac-then-acrypt ciphers used in TLS 1.0, but they're easily mitigated by negotiating EtM: https://datatracker.ietf.org/doc/html/rfc7366#section-2 In any case, communication with legacy systems via TLS 1.0 is substantially safer than in the clear. -- Viktor.
Thing is, you are doing analysis to argue that your usage is safe enough. Which is exactly the kind of overhead you'll have to do whenever the security landscape changes. Also, it would likely be a good idea to add some push towards 1.2. If entire ecosystems still stick with 1.x, they're rotten. I know that some ecosystems just are that way; the best we can do is to add some small push towards a better policy, and it's the least we *should* do. Regards, Jo
On Fri, Jan 19, 2024 at 10:29:27PM +0100, Jo Durchholz wrote:
Thing is, you are doing analysis to argue that your usage is safe enough. Which is exactly the kind of overhead you'll have to do whenever the security landscape changes.
My use case is basically opportunistic TLS in SMTP, which is typically unauthenticated, and best-effort (also DoT to auth in DNS). TLS 1.0 is better than cleartext. I am also operating a broad deployment survey, and the survey needs to be able to connect with whatever the other end supports. Security against active attacks is irrelevant. I am not suggesting that anyone should stick with TLS 1.0, though it is in practice "good enough" in some applications. Its deployment numbers are substantially lower and falling. I was just asking that TLS 1.0 continue to be available when explicitly requested, rather than removed.
Also, it would likely be a good idea to add some push towards 1.2. If entire ecosystems still stick with 1.x, they're rotten. I know that some ecosystems just are that way; the best we can do is to add some small push towards a better policy, and it's the least we *should* do.
The push has already happened, TLS 1.3 is widely available and is negotiated by default when supported by both ends. The negotation is downgrade-resistant. It is addition of TLS 1.3 support, not removal of TLS 1.0 support that has the biggest impact on improved security. There are however still some pockets of devices and systems, and it is a judgement call as to when it is appropriate to cut off interoperability with those systems. Yes, it could be now, but a case can be made that this does not improve security, though it does perhaps reduce support effort if there is still a real support burden in keeping the TLS 1.0 code working. -- Viktor.
Thanks for the explanations; I now have a better understanding of the issues at hand, and I hope this has helped others as well. My personal take would be to move TLS 1.0/1 out into a separate library, say, tls-deprecated. One, this clearly marks the mechanism as something not to be used unless you really need it. Second, people who just use TLS will stick with the standard tls library, and won't get old TLS activated by some funny accident (such as misconfiguration); after all, code that isn't there can't be involved in some security shenanigans. Just my 2 cents, trying to reconcile legacy needs and security-by-design aspects as far as possible. I hope it helps somebody. Regards, Jo
This can be a good use for a cabal flag. You can have a manual,
off-by-default flag that enables it. Then you don't need another package.
M
On Fri, 19 Jan 2024, 22:44 Jo Durchholz,
Thanks for the explanations; I now have a better understanding of the issues at hand, and I hope this has helped others as well.
My personal take would be to move TLS 1.0/1 out into a separate library, say, tls-deprecated. One, this clearly marks the mechanism as something not to be used unless you really need it. Second, people who just use TLS will stick with the standard tls library, and won't get old TLS activated by some funny accident (such as misconfiguration); after all, code that isn't there can't be involved in some security shenanigans.
Just my 2 cents, trying to reconcile legacy needs and security-by-design aspects as far as possible. I hope it helps somebody.
Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
On Fri, 19 Jan 2024, Michael Peyton Jones wrote:
This can be a good use for a cabal flag. You can have a manual, off-by-default flag that enables it. Then you don't need another package.
The API should never depend on a Cabal flag, because an importing package cannot specify a flag in Build-Depends.
On Sat, 20 Jan 2024, Henning Thielemann wrote:
On Fri, 19 Jan 2024, Michael Peyton Jones wrote:
This can be a good use for a cabal flag. You can have a manual, off-by-default flag that enables it. Then you don't need another package.
The API should never depend on a Cabal flag, because an importing package cannot specify a flag in Build-Depends.
However, a solution might be, that both tls-1.x and tls-2.x branches are kept maintained and get regular updates.
Hi, I hit upon a solution for Viktor. TLS 1.0/1.1 code is kept and enabled via a special parameter. Old cipher suites including CBC are provided by "tls-insecure" or something. I'm surprised because Jo already proposed the same solution. :-) So, I would support his proposal. Viktor, could you volunteer to maintain the "tls-deprecated" package? --Kazu
Thanks for the explanations; I now have a better understanding of the issues at hand, and I hope this has helped others as well.
My personal take would be to move TLS 1.0/1 out into a separate library, say, tls-deprecated. One, this clearly marks the mechanism as something not to be used unless you really need it. Second, people who just use TLS will stick with the standard tls library, and won't get old TLS activated by some funny accident (such as misconfiguration); after all, code that isn't there can't be involved in some security shenanigans.
Just my 2 cents, trying to reconcile legacy needs and security-by-design aspects as far as possible. I hope it helps somebody.
Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
On Sun, Jan 21, 2024 at 09:09:45AM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote:
I hit upon a solution for Viktor. TLS 1.0/1.1 code is kept and enabled via a special parameter. Old cipher suites including CBC are provided by "tls-insecure" or something.
Thanks, can you be more specific? Is this a run-time or build-time flag? [ FWIW, properly used, e.g. with Encrypt-then-MAC (EtM) CBC ciphers are actually more robust in practice than GCM, because they're not subject to complete failure on nonce reuse. ]
I'm surprised because Jo already proposed the same solution. :-) So, I would support his proposal.
Viktor, could you volunteer to maintain the "tls-deprecated" package?
Can you elaborate on what's involved? I may be able to make sure it builds with recent-enogh GHC, ... if that's the bulk of the effort and there are no new features to worry about. -- Viktor.
Thanks, can you be more specific? Is this a run-time or build-time flag?
Via "Supported" in ClientParams/ServerParams.
Can you elaborate on what's involved? I may be able to make sure it builds with recent-enogh GHC, ... if that's the bulk of the effort and there are no new features to worry about.
Probably, testing and/or checking version boundaries when a new version of "tls" is released. And upload a new version or modify the metadata on Hackage. --Kazu
Hi Viktor,
I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any chance you could find some way to explicitly keep these protocol versions enabled?
The answer is no. You might want to stick to tls v1.9.x. P.S. According tests with Qualys SSL Labs, the following browsers cannot communicate with tls v2.0.0: IE 11 / Win 7 IE 11 / Win 8.1 IE 11 / Win Phone 8.1 IE 11 / Win Phone 8.1 Update Safari 6 / iOS 6.0.1 Safari 7 / iOS 7.1 Safari 7 / OS X 10.9 Safari 8 / iOS 8.4 Safari 8 / OS X 10.10 They are quite outdated. --Kazu
On Fri, Jan 19, 2024 at 06:21:13PM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote:
Hi Viktor,
I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any chance you could find some way to explicitly keep these protocol versions enabled?
The answer is no.
You might want to stick to tls v1.9.x.
That's unfortunate.
P.S.
According tests with Qualys SSL Labs, the following browsers cannot communicate with tls v2.0.0:
IE 11 / Win 7 IE 11 / Win 8.1 IE 11 / Win Phone 8.1 IE 11 / Win Phone 8.1 Update Safari 6 / iOS 6.0.1 Safari 7 / iOS 7.1 Safari 7 / OS X 10.9 Safari 8 / iOS 8.4 Safari 8 / OS X 10.10
They are quite outdated.
TLS is not just for the web. There are various application ecosystems that are noticeably less agile than web browsers, and substantially not at risk from the various browser-related attacks on TLS 1.0. Note that barring new handshake downgrade attacks, security is improved by raising the ceiling (making more secure options available and on by default) than by raising the floor (possibly leading to some communication using cleartext instead). The suggestion that I should consider cleartext instead of TLS 1.0 is a clear case of letting the perfect be the enemy of the good. In RFC 7435, I made a case for a more practical approach. -- Viktor.
Hi Viktor,
TLS is not just for the web. There are various application ecosystems that are noticeably less agile than web browsers, and substantially not at risk from the various browser-related attacks on TLS 1.0.
Why cannot you switch to TLS 1.2? TLS 1.2 is 16 year old, very similar to TLS 1.0 and much more secure. --Kazu
On Fri, Jan 19, 2024 at 06:41:55PM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote:
TLS is not just for the web. There are various application ecosystems that are noticeably less agile than web browsers, and substantially not at risk from the various browser-related attacks on TLS 1.0.
Why cannot you switch to TLS 1.2?
I don't control the software stacks used by others, with whom I still need to communicate. Or with legacy devices, ...
TLS 1.2 is 16 year old, very similar to TLS 1.0 and much more secure.
But note that TLS 1.0 is much more secure than cleartext. It is fine to disable it by default, but I would prefer that it still be available. -- Viktor.
participants (5)
-
Henning Thielemann -
Jo Durchholz -
Kazu Yamamoto -
Michael Peyton Jones -
Viktor Dukhovni