Encrypted SNI can’t work against active attackers: on 1.3 failure, browsers will fallback to 1.2 which leaks it before downgrade is detected
-
-
@BRIAN_____ some stupid firewalls and middleboxes will drop 1.3 CH, forcing fallback -
@FiloSottile Easily fixable by making ClientHello.client_version be 0x0303 again like 1.2. I agree encrypted SNI seems to have limits. -
@BRIAN_____ however the CH looks like I don't understand how a 1.2/1.3 client can avoid falling back to plain SNI /cc@sleevi_@grittygrease -
@FiloSottile@sleevi_@grittygrease Yes, that's what I meant about "I agree encrypted SNI seems to have limits." -
@BRIAN_____ ah sorry, 140 chars and all :) -
@FiloSottile It would prb be reasonable to have fallback from TLS 1.3 ClientHello w/ encrypted SNI to TLS 1.3 ClientHello w/ plaintext SNI. -
@FiloSottile But, I don't want the only way to do things compatibility to be TLS 1.3 w/ encrypted SNI -> TLS 1.2.
End of conversation
New conversation -
-
-
@BRIAN_____@FiloSottile Most clients will do fallback for years. -
@grittygrease@BRIAN_____@FiloSottile Citation needed? Chromies have been spending the past 18months killing fallbacks. -
@sleevi_@BRIAN_____@FiloSottile With MiTM position, you can always make a server look like it doesn't support the latest version of TLS. -
@grittygrease@sleevi_@BRIAN_____ in particular if SNI is enc. a 1.2 server can’t just go “huh, I’ll answer as a 1.2 CH”, needs fallback
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.