3 ms·
I'm writing (as a side project) a game with a client-server system. For the server, I'm using dot-net's SslStream (in TLS mode) and it needs to know which TLS
by billpg 4y ago
I'm writing (as a side project) a game with a client-server system.
For the server, I'm using dot-net's SslStream (in TLS mode) and it needs to know which TLS cert to use prior to handing over control of the connection.
For this reason, I've designed the protocol for the client to announce who they are and what they want as a single line of JSON before letting SslStream negotiate TLS. Once the connection is secured, the client repeats that first line of JSON. If the server detects any difference between the two it closes down the connection. (I also made sure to clear the buffers after reading that first line of JSON.)
I don't like doing that but the only other way is to "roll my own crypto" which I understand is a bad thing.
- d-z-m 4y agoSniffing the SNI from the underlying TCP connection is the proper way to do this. a couple examples I know of(only know go ones of the top of my head): https://github.com/fabiolb/fabio/blob/master/proxy/tcp/tls_clienthello.go https://github.com/fabiolb/fabio/blob/master/proxy/tcp/tls_c... https://github.com/FiloSottile/mostly-harmless/blob/main/talks/asyncnet/tls.go https://github.com/FiloSottile/mostly-harmless/blob/main/tal... > I don't like doing that but the only other way is to "roll my own crypto" which I understand is a bad thing. You would not be rolling your own cryptographic primitive, or combining existing ones in strange and speculative ways. This is what most people, most of the time mean when they admonish against rolling your own crypto. All you'd have to do is parse the ClientHello to retrieve the SNI. you're in a memory safe language, so parsing bugs result in a crash, not a buffer overflow. I'd say you're on pretty firm ground.
- hannob 4y ago> it needs to know which TLS cert to use prior to handing over control of the connection It is a bit unclear here what that means. I mean TLS has a mechanism to choose the certificate based on the hostname (SNI). Other than that - why would a different user get a different certificate? After all the certificate's job is to identify the server.
- billpg 4y agoThat's a flaw in dot-net's SslStream library. You don't get an opportunity to know what host the client is expecting before selecting the cert for this session. Reading discussions around this issue usually settle on reading and parsing the "ClientHello" to extract the SNI name, and then hacking the ClientHello back into the incoming stream so TLS code can read it.