-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does TLS 1.3 meet all these properties? #25
Comments
Yes, most of secret-handshake predates TLS 1.3 by a bit. The only thing that usually isn't desired for HTTPS settings is the property that the initiator (usually called client) needs to know the public key of the responder (aka server) before hand. Just for redundancy if that statement was wonky: Not certificate pinning. A connection can't be established with SHS unless the public key of the server is known to the client at the beginning of the handshake.. |
I'm aware of that. But is the rest of my initial message correct?
Interesting, thanks. What security benefits does that have specifically? It prevents attackers from figuring who is at an address just by connecting I guess? One thing I did notice is that the server authenticates first for TLS, which differs from the model in the paper, where the client authenticates first.
It also means that the server's public key is not really secret for TLS, because even though it's encrypted, any attacker could just connect to the same server and get it. I think. |
I believe that TLS 1.3 meets all the security requirements in the README. TLS 1.2 does not, but 1.3 does because all handshake messages after ServerHello are encrypted, which includes the server certificate and therefore the server's public key.
Am I correct about this?
The text was updated successfully, but these errors were encountered: