Hi, [ not subscribed to the list, Cc me on replies please ] I'm trying ocserv 0.1.2 in combination with Debian wheezy's openconnect (3.20). It looks like there is a bug in the way ocserv uses the http-parser library that results in misparsing the HTTP headers and X-DTLS-Master-Secret specifically, which in turn results in DTLS being disabled. More specifically, ocserv reads from the socket and feeds the buffer to http-parser as it goes, with http-parser potentially trying to parse partial header fields/values. X-DTLS-Master-Secret is being received one byte at a time, which results in lines like: ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: 54 ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: D7 ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: 7F ocserv[30247]: [2001:(...)]:43911 HTTP: X-DTLS-Master-Secret: 62 and ocserv takes no special provisions on concatenating all those values; it just compares their length (1) to TLS_MASTER_SIZE*2 and if it's smaller, outright rejects the key. This is not X-DTLS-Master-Secret / DTLS specific at all, but rather a flaw on how the http-parser API is being used by ocserv in general. It just happened due to openconnect client's implementation to hit this in X-DTLS-Master-Secret values but it could have happened in other header values or even field names. The misuse of the API is actually documented on http-parser's documentation[1]: "Reading headers may be a tricky task if you read/parse headers partially. Basically, you need to remember whether last header callback was field or value and apply following logic [...] Value continues. Reallocate value buffer and append callback data to it". I could give a stab at a fix, although it looks like it would be fairly invasive on the HTTP handling codepath so I figured you might want to redesign this yourself :) Cheers, Faidon 1: https://github.com/joyent/http-parser
