Re:AT&T Fiber in the SF Bay Area is flipping bits
by superjan on Tuesday December 08, 2020 @05:09AM
(#25343608)
Thanks for sharing this! I have long suspected that TLS does this. It is great: for many applications preventing bitflips in transit is arguably more important than privacy. Is there an authorative source where this is documented?
Re:AT&T Fiber in the SF Bay Area is flipping bits
by tialaramex on Tuesday December 08, 2020 @09:14PM
(#25354534)
You mean besides the RFCs (the most recent RFC 8446 describes TLS 1.3) ?
https://tools.ietf.org/html/rfc8446
If you aren't interested in why this works just the Introduction to the RFC explains the intent, specifically what we care about here is that TLS delivers:
"Integrity: Data sent over the channel after establishment cannot be modified by attackers without detection."
And further notes "These properties should be true even in the face of an attacker who has complete control of the network".
Re:AT&T Fiber in the SF Bay Area is flipping bits
by SV_BubbleTime on Tuesday December 08, 2020 @12:13AM
(#25342127)
Help me understand, are you saying only HTTP bits are being flipped? Because yea, if a HTTPS bit was flipped the whole packet dies. So is this issue blowing up all sorts of traffic everywhere?
Re:AT&T Fiber in the SF Bay Area is flipping bits
by X-Istence on Tuesday December 08, 2020 @02:31AM
(#25342826)
Yes, all bits are being flipped. TLS connections drop because the message can't be authenticated, HTTP or other plaintext protocols will continue on with bad data.
So yes, it is blowing up all sorts of traffic everywhere. You just don't notice when it is plaintext.
Not just in the handshake, TLS moves these things called TLSPlaintext records (about 16kbytes each), not only in the handshake, but also for all the actual data - and they'll always have integrity protection to ensure bad guys can't change anything. TLS can't know the difference between a bad guy tampering with data and your crappy Internet mangling the data in transit, in either case the TLS protocol design says to "alert" bad_record_mac which your browser or similar software will probably treat as a failed connection, even if it happens mid-way through an HTTP transaction.
Because TLS guarantees integrity even if your fiber is a complete shit show, any TLSPlaintext records which do get from one end to the other are guaranteed to be as intended.