SNI is not always provided when using QUIC
Reported by
thomas.d...@gmail.com,
May 8 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. Host a QUIC server (I use Caddy server) with an IP-address as url or a hostname without top-level domain (eg blabla) 2. Use chromium with --origin-to-force-quic-on=blabla:2020 to surf to the QUIC site 3. What is the expected behavior? A working QUIC connection What went wrong? The QUIC server aborts the connection because Chromium does not provide a SNI in the QUIC ClientHello. Maybe it should never provide an SNI for hostnames that are not strictly correct>h However this way it is impossible to even start a QUIC connection to localhost Did this work before? No Chrome version: 58.0.3029.81 Channel: stable OS Version: Ubuntu 17.04 Flash Version: Shockwave Flash 25.0 r0
,
May 8 2017
,
May 8 2017
FWIW, the specification for SNI says that IP literal addresses should not be used in the client's SNI (irrespective of QUIC). However, I'm not aware of any such restriction on unqualified hostnames.
,
May 8 2017
So for literal IP's this is not a bug, but still this breaks using QUIC over localhost
,
May 8 2017
Removing the SSL label. The TLS spec for SNI doesn't currently impose any normative requirements on QUIC as QUIC uses its own crypto protocol. In the future, QUIC will be using an embedding of TLS 1.3, at which point it will, so it does make sense for QUIC of today to align. And, yeah, it does seems odd to me if we don't send it for localhost, but I'll leave it to the QUIC folks to decide on that one.
,
May 9 2017
,
May 9 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by thomas.d...@gmail.com
, May 8 2017