Changes Coming to TLS: Part Two(access.redhat.com)
access.redhat.com
Changes Coming to TLS: Part Two
https://access.redhat.com/blogs/766093/posts/2978671
28 comments
Will Cloudflare be open sourcing the TLS 1.3 code to nginx or is this something we have to wait for nginx to add support to?
Alternative title: "Sanity Coming to TLS"
Yes. It's mostly about taking stuff out.
Did OpenSSL take out the "debug feature" which bypasses encryption and logs keys if you set an environment variable?
Did OpenSSL take out the "debug feature" which bypasses encryption and logs keys if you set an environment variable?
1. That feature is a feature of the OpenSSL implementation, not a feature of TLS itself.
2. It's also incredibly useful for debugging SSL implementations. (Much more so than as some sort of backdoor, since that's what you seem to be implying.)
2. It's also incredibly useful for debugging SSL implementations. (Much more so than as some sort of backdoor, since that's what you seem to be implying.)
I don't know of an environment variable to enable that with OpenSSL, but there is one for NSS. For recent versions it has to be enabled at compile time, but it's enabled for the official Firefox binaries.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...
Without that, you can't intercept https traffic and analyse it properly with tools like charles or wireshark. They both rely on reading the keyfile openssl et al write out when triggered to do so.
Do you have a pointer to that variable, code or doc? A web search didn't return anything obvious.
SSLKEYLOGFILE is the one that a few implementations use.
Looking forward to TLS 1.3. Starting testing Nginx 1.11.13 + OpenSSL 1.1.0 draft 18 branch with TLS 1.3 myself https://community.centminmod.com/posts/47692/ not quite there yet. Needs some love on Nginx end too :)
> If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 01
If it is possible to do this safely, does that mean the TLS 1.2 Random value was always eight bytes too long? Or that it was unnecessary?
If it is possible to do this safely, does that mean the TLS 1.2 Random value was always eight bytes too long? Or that it was unnecessary?
SSLv2-style ClientHellos typically used a 16 byte random. Current ones always use a 32 byte random.
[deleted]
Most of these changes seem to just disallow weak cipher suites and RTT-1/0 connections.
Are there any other differences between modern TLS 1.2 setup and TLS 1.3?
Are there any other differences between modern TLS 1.2 setup and TLS 1.3?
You should read Part One of the series (https://access.redhat.com/blogs/766093/posts/2975791) which talks about the handshake changes
As I understand it, they are also removing raw public keys and OpenPGP keys, keeping only X.509 certificates.
From the github repo looks like raw public keys are supported but openpgp not :
https://github.com/tlswg/tls13-spec/issues/929
https://github.com/tlswg/tls13-spec/issues/937
https://github.com/tlswg/tls13-spec/issues/929
https://github.com/tlswg/tls13-spec/issues/937
Which is quite sad since OpenPGP keys, unlike X.509 certificates, are allowed to carry signatures from multiple private keys instead of just one.
Did anyone use OpenPGP for this? Seems interesting...
The project I co-designed still use this. It’s also supported by mod_gnutls for Apache.
Is this only to check server identity or client as well?
Why not use regular X 509 certs?
Why not use regular X 509 certs?
Only server identity. Our situation in our project is that the TLS server side already has an OpenPGP key for other purposes anyway, so it is very practical to use it as an identity check inherent in the TLS handshake.
On the topic of X.509 certificates, I can only point to Peter Gutmann: Everything you Never Wanted to Know about PKI but were Forced to Find Out (https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf) Basically, X.509 certificates are very complex, and many security bugs have historically been found in the parsing code for them.
On the topic of X.509 certificates, I can only point to Peter Gutmann: Everything you Never Wanted to Know about PKI but were Forced to Find Out (https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf) Basically, X.509 certificates are very complex, and many security bugs have historically been found in the parsing code for them.
Is there any reason not to use IPSec instead of TLS?
They address totally different use cases.
To my knowledge both can be used for most use-cases. Do you have something specific in mind where TLS would shine but IPSec would not?
IPsec requires cooperation and setup from both the OS and any middleboxes. TLS typically does not.
Putting it another way, TLS is actually usable in arbitrary applications, IPsec is definitely not.
Putting it another way, TLS is actually usable in arbitrary applications, IPsec is definitely not.
Current popular implementations of it. There is nothing technical in IPSec per se stopping it from being implemented as a library, userspace server, or anything like that.
In reverse, IPSec is typically usable in arbitrary protocols and applications without special support for it, unlike TLS.
In reverse, IPSec is typically usable in arbitrary protocols and applications without special support for it, unlike TLS.
Things could always be different, but thats not a useful discussion when you are concerned about how things are, and working with them.
https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...