ocserv: http parsing flaw results in disabled DTLS

[Faidon Liambotis]

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