
Changes Coming to TLS: Part Two - remx
https://access.redhat.com/blogs/766093/posts/2978671
======
FiloSottile
If you prefer the video format, Nick and I gave a talk at 33c3 about how TLS
1.3 works and our experience deploying it at Cloudflare.

[https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...](https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad)

~~~
newman314
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?

------
okket
Alternative title: "Sanity Coming to TLS"

~~~
Animats
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?

~~~
walterbell
Do you have a pointer to that variable, code or doc? A web search didn't
return anything obvious.

~~~
dvorak42
SSLKEYLOGFILE is the one that a few implementations use.

------
vbtechguy
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/](https://community.centminmod.com/posts/47692/)
not quite there yet. Needs some love on Nginx end too :)

------
zedred
> 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?

~~~
yuhong
SSLv2-style ClientHellos typically used a 16 byte random. Current ones always
use a 32 byte random.

------
hdhzy
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?

~~~
ninju
You should read Part One of the series
([https://access.redhat.com/blogs/766093/posts/2975791](https://access.redhat.com/blogs/766093/posts/2975791))
which talks about the handshake changes

------
teddyh
As I understand it, they are also removing raw public keys and OpenPGP keys,
keeping only X.509 certificates.

~~~
hdhzy
Did anyone use OpenPGP for this? Seems interesting...

~~~
teddyh
The project I co-designed still use this. It’s also supported by mod_gnutls
for Apache.

~~~
hdhzy
Is this only to check server identity or client as well?

Why not use regular X 509 certs?

~~~
teddyh
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](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.

------
snakeanus
Is there any reason not to use IPSec instead of TLS?

~~~
yjftsjthsd-h
They address totally different use cases.

~~~
snakeanus
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?

~~~
throwaway2048
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.

~~~
snakeanus
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.

~~~
throwaway2048
Things could always be different, but thats not a useful discussion when you
are concerned about how things are, and working with them.

