2

If I need't a secure data. Can I use TLS without QUIC? Why must use TLS with QUIC?

Thanks.

Jim
  • 31
  • 1
  • You may want to read Troy Hunt's [Here's Why Your Static Website Needs HTTPS](https://www.troyhunt.com/heres-why-your-static-website-needs-https/) which will delve into the same areas. Basically, nobody thinks delivering sites in the clear makes much sense these days, so the protocols being built tend to assume that too. – Damien_The_Unbeliever Jul 01 '22 at 09:11
  • Thanks you reply, I think it is reasonable in the case of HTTPS, however, I see most people compare it to TCP, but actually TCP doesn't need TLS, so how do I understand the role of TLS over QUIC? – Jim Jul 01 '22 at 09:45
  • QUIC RFC requires it to be secured. TLS handshake is a necessary part of the QUIC handshake (unlike with TCP, where TLS handshake follows TCP handshake). If you want your application to establish connections with other QUIC servers over the internet, you need to comply with the IETF standard and thus encrypt your data. – nnori Dec 28 '22 at 18:19

1 Answers1

1

I assume you meant:

Can I use QUIC without TLS?

Yes and no.

Both RFC 9000 and RFC 9001 (the QUIC standard) require QUIC to be secure, and through TLS. And it is highly unlikely you will see a QUIC server on the internet that is not encrypted.

But what exactly is stopping you from doing whatever you want? In particular using QUIC without encryption? In fact there already are implementations that allow it.

That being said, I encourage you to actually always use encryption, even for testing or development. It is a good practice. Because it is mandatory for production (otherwise it is not safe, unless you use it in a weird setup like locally without network), and it is a good idea to keep different envs as close to each other as possible. In order to avoid subtle issues.

freakish
  • 54,167
  • 9
  • 132
  • 169
  • 3
    Actually, it's just 'no'. The entire QUIC handshake uses mandatory encryption, and there is no valid version of the initial handshake that does not use (or reuse) packet protection keys that are derived during the TLS exchange. You could of course choose to build a stack that does not implement the TLS exchange, but then it wouldn't be QUIC, and you wouldn't be able to connect to anything that is compliant. _"In fact there already are implementations that allow it."_ do you have a reference? – Buffoonism Jul 25 '22 at 08:13
  • 1
    @Buffoonism that's not a surprise that unencrypted connection won't work with an encrypted one. I know one such implementation: https://github.com/Vect0rZ/Quic.NET – freakish Jul 25 '22 at 08:39
  • 2
    Actually that link kind of confirms what I said, no? It's for a half-finished implementation, that doesn't cover the final RFC, and says it specifically doesn't implement the TLS required to be compliant with the standard. i.e it's not QUIC. – Buffoonism Jul 25 '22 at 08:52
  • @Buffoonism you're turning this into a linguistic discussion now. Whether you call a non-encrypted QUIC as QUIC or not, is not that important. At least for me. And yes, non-encrypted QUIC is prohibited by RFCs, I already said that in my answer. – freakish Jul 25 '22 at 08:59
  • In the same way that TCP without the handhake is still TCP? ;) – Buffoonism Jul 25 '22 at 09:13
  • There are cases where you want your internal HTTP API's to communicate without the need of encryption. – Theodore Zographos Nov 24 '22 at 19:17