Skip to content
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

Open
makew0rld opened this issue Mar 23, 2021 · 2 comments
Open

Does TLS 1.3 meet all these properties? #25

makew0rld opened this issue Mar 23, 2021 · 2 comments

Comments

@makew0rld
Copy link

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?

@cryptix
Copy link
Contributor

cryptix commented Mar 23, 2021

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

@makew0rld
Copy link
Author

Yes, most of secret-handshake predates TLS 1.3 by a bit.

I'm aware of that. But is the rest of my initial message correct?

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

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.

Requiring Alice [client] to authenticate first is unusual, but I think this is a fair deal. Bob [server] has already put himself at a disadvantage by allowing himself to be publicly addressable. It’s only fair that Alice authenticates first. By encrypting her authentication she need not reveal her identity to anyone but the one true Bob. Likewise, if Bob chooses not to accept the call, then Alice won’t be able to deduce whether or not it was really Bob. Maybe it was but he did not wish to speak to her? Maybe it was just a wrong number? This protects Bob from harassment.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants