Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every Byte of a TLS Connection Explained and Reproduced

tls.ulfheim.net

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Every Byte of a TLS Connection Explained and Reproduced

#91

Post by syncsynchalt »

userbinator wrote: post #89

The parties had agreed on a cipher suite using ECDHE, meaning the keypairs will be based on a selected Elliptic Curve, Diffie-Hellman will be used, and the keypairs will be Ephemeral rather than using the public/private key from the certificate. I think it's important to mention that even with ephemeral cipher suites, the server's ephemeral public key is signed using the server's certificate private key and verified…

It’s in the Server Key Exchange record (from memory) but i probably didn’t explain it well.

Re: Every Byte of a TLS Connection Explained and Reproduced

#92

Post by jwilk »

School-Cotton wrote: post #90
userbinator wrote: post #88

Earlier quoted context omitted.

TLS 1.3 capable servers also scribble "DOWNGRD" in part of the random field if a client message says it can't do TLS 1.3. If a TLS 1.3 client sees that unusual "random" choice it knows bad guys tampered with the connection (attempted a downgrade attack). If bad guys just change the values, they won't match between client and server and the connection aborts. Older clients think nothing of the unusual random value and…

The probability of a particular seven bytes occurring by chance is less than one in a billion billion billion billion.

256⁷ ≈ 7.2E16, which is much less than billion⁴ = 1E36.

Still, the likelihood of this happening by chance is miniscule.

Re: Every Byte of a TLS Connection Explained and Reproduced

#93

Post by the_clarence »

pimlottc wrote: post #25
bungie4 wrote: post #12

Beautiful. I recently had to implement two way auth over 1.2 and this would have saved much hair pulling. (and who does TWO way auth over an MPLS connection. Turns out, us).

I feel your pain. Two-way TLS is a funny thing, it's supported by the standards and even most implementations but its actual use is minuscule compared to "normal" one-way TLS, so much so that it's hard to find documentation even acknowledging two-way TLS exists, let alone how to use it. And don't get me started about the hassles of obtaining signed certificates that are actually usable for client auth...

That's what the Noise protocol framework is for.

Re: Every Byte of a TLS Connection Explained and Reproduced

#94

Post by the_clarence »

userbinator wrote: post #87
toast0 wrote: post #22

This is wonderful! I may make a version where the bytes used for lengths are highlighted, since it feels like so many bytes are lengths; look at the SNI extension, which has three 16-bit lengths, I know why they're there, but SNI probably shouldn't be a list, and even if it was a list, an extension that consists solely of a list has a list of the length of the extension, you shouldn't need two bytes for that, and if…

Moreover, from a security perspective since we're talking about TLS, "overspecified" and/or "redundant" lengths are just begging to be made inconsistent and a source of vulnerabilities.

Usually if you mess up something there your implementation just doesn't work.

Re: Every Byte of a TLS Connection Explained and Reproduced

#95

Post by tialaramex »

jwilk wrote: post #92
School-Cotton wrote: post #90

Earlier quoted context omitted.

The probability of a particular seven bytes occurring by chance is less than one in a billion billion billion billion.

256⁷ ≈ 7.2E16, which is much less than billion⁴ = 1E36. Still, the likelihood of this happening by chance is miniscule.

The actual feature uses an 8-byte value, it's just that the DOWNGRD part (the first 7 bytes) is intuitively easy to follow so why spell it all out in hexadecimal or whatever.

So it's one in 2^64 random connections

Also the client isn't even checking for possible downgrade if it got the protocol version it wanted (if I wanted TLS 1.3 and I got TLS 1.3 that is not a downgrade). So if "One in every 16 billion billion connections fails" is unacceptable, upgrade your servers and the problem vanishes.

Re: Every Byte of a TLS Connection Explained and Reproduced

#97

Post by School-Cotton »

jwilk wrote: post #92
School-Cotton wrote: post #90

Earlier quoted context omitted.

The probability of a particular seven bytes occurring by chance is less than one in a billion billion billion billion.

256⁷ ≈ 7.2E16, which is much less than billion⁴ = 1E36. Still, the likelihood of this happening by chance is miniscule.

You’re right, not sure how I screwed up the math

Re: Every Byte of a TLS Connection Explained and Reproduced

#99

Post by e12e »

gbajson wrote: post #46

Has anyone of you seen such beautiful explanation for other protocols (TCP, 4-way handshake)?

I'm reminded about the STEPS report of using ascii art from the rfcs as a DSL for describing tcp:

Writeup/comment: http://www.moserware.com/2008/04/towards-moores-law-software...

Comment thread: https://news.ycombinator.com/item?id=846028

The vpri texts: http://www.vpri.org/writings.php

Appendix e and section "A Tiny TCP/IP Using Non-deterministic Parsing" of "STEPS Toward The Reinvention of Programming: First Year Progress Report, December 2007.":

http://www.vpri.org/pdf/tr2007008_steps.pdf

Re: Every Byte of a TLS Connection Explained and Reproduced

#100

Post by e12e »

deaps wrote: post #42
gear54rus wrote: post #34

Earlier quoted context omitted.

If I'm not mistaken, its not UDP, it's ICMP, like you said

Ahh yeah - good call. Totally different protocol. I guess ICMP more closely resembles UDP at the end of the day, but you're absolutely right. I edited out the incorrect UDP reference so that a person reading for the first time will not get misled. Thanks!

Which is also why some poorly configured network devices firewalls will eat pings - if they for example whitelist tcp and udp protocols and drop everything else (yes, that's a bad idea).

https://security.stackexchange.com/questions/22711/is-it-a-b...

Post reply on HN