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

MsQuic – QUIC Implementation from Microsoft

github.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: MsQuic – QUIC Implementation from Microsoft

#81

Post by protz »

catalin_hritcu wrote: post #80
profquail wrote: post #65

Earlier quoted context omitted.

Have you considered implementing any parts of this in F* (so they can be verified) and extracting back to C, as is being done for TLS? https://project-everest.github.io/

Some work on verifying QUIC packet encryption using F* is happening at Microsoft Research: https://github.com/project-everest/everquic-crypto

Just to build on Catalin's answer. We are actively working on an implementation of QUIC's transport layer (i.e. packet encryption and decryption), along with a proof of cryptographic security. This is what Catalin linked to (https://github.com/project-everest/everquic-crypto). EverQuic-Crypto builds upon two previous projects: EverParse, a library of verified low-level parsers and serializers which we apply to the QUIC network formats, and EverCrypt, a cryptographic provider with agility and multiplexing, which we use for all the cryptography, e.g. packet number encryption, AEAD, etc.

This is not yet a full QUIC implementation, but we have plans for extending this codebase to cover more of the QUIC protocol.

Re: MsQuic – QUIC Implementation from Microsoft

#82

Post by tialaramex »

fulafel wrote: post #75
dochtman wrote: post #58

Earlier quoted context omitted.

Though it has been discussed that future versions of QUIC might allow other authentication/encryption protocols. Noise would be an interesting candidate.

Note that TLS doesn't necessarily imply certs either. TSL-PSK, TLS-SRP, anon DH, etc.

Sure, but, it's important to caveat that QUIC requires specifically TLS 1.3 (or potentially subsequent versions in the future) and so features which require older TLS versions aren't useful.

Pre-shared keys are a thing in TLS 1.3 though there are subtle differences you ought to be aware of before implementing, but as I understand it SRP is not (at time of writing) and neither is anonymity.

It isn't possible to "just" take an extension to TLS 1.2 that altered the handshake mechanism and have it work in TLS 1.3 because the handshake is very different even though it was camouflaged so that rusted-in-place TLS 1.2 middleboxes think it's just TLS 1.2 and don't freak out.

Re: MsQuic – QUIC Implementation from Microsoft

#84

Post by skyde »

slowstart wrote: post #4

Please fire away any questions you may have! I lead the team that built this library. This blog has details on current development status and adoption within Microsoft: https://techcommunity.microsoft.com/t5/networking-blog/msqui...

will it be possible to use the « sendfile » system call to do zero copy file transfers on a quick connection?

Re: MsQuic – QUIC Implementation from Microsoft

#85

Post by legulere »

ComodoHacker wrote: post #41
legulere wrote: post #21

> MsQuic is shipped in-box in the Windows kernel in the form of the msquic.sys driver Does that mean that a HTTP.SYS Webserver will also Support QUIC?

You mean IIS? HTTP.SYS isn't a webserver.

The kernel module HTTP.SYS contains a HTTP server. It's used by IIS, but you can also use its API directly.

Re: MsQuic – QUIC Implementation from Microsoft

#86

Post by ComodoHacker »

legulere wrote: post #85
ComodoHacker wrote: post #41

Earlier quoted context omitted.

You mean IIS? HTTP.SYS isn't a webserver.

The kernel module HTTP.SYS contains a HTTP server. It's used by IIS, but you can also use its API directly.

Wow, didn't know that.

API for the curious: https://docs.microsoft.com/en-us/windows/win32/http/http-api...

Re: MsQuic – QUIC Implementation from Microsoft

#87

Post by Ericson2314 »

nxc18 wrote: post #61
garaetjjte wrote: post #56

Earlier quoted context omitted.

>I am impressed by the quality of Windows 10 Weird, I must have some different edition of Windows. Totally inconsistent settings/control panel interfaces, updates taking ages, updates failing when you look at it wrong (and then stuck in update-revert loop every boot), driver setup taking minutes, and I constantly discover some new disk-hogging background process.

You're forgetting about the comparison to a linux desktop though. I personally would really love to switch to Ubuntu full time, but I'm not going to forgive it soon for bricking my machine after a software update. Unfortunately for Linux, the automated recovery tools just aren't there like on Windows - if a Windows update breaks the system, it will be able to recover itself 90% of the time. Yeah, the UI is shitty and…

NixOS's rollbacks make the updating safer than Windows or regular Linux distros.
Post reply on HN