HN Explorer

28 comments

[ 3.4 ms ] story [ 101 ms ] thread
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.
duskwuff
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.)

chillydawg
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.
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?

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.
[deleted]
(comment deleted)
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.
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) Basically, X.509 certificates are very complex, and many security bugs have historically been found in the parsing code for them.

snakeanus
Which is quite sad since OpenPGP keys, unlike X.509 certificates, are allowed to carry signatures from multiple private keys instead of just one.