-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marcin,
This should fix it:
diff --git a/src/protocol.c b/src/protocol.c index 16b87e7..8eb8dee 100644 - --- a/src/protocol.c +++ b/src/protocol.c @@ -980,6 +980,9 @@ NOEXPORT void ntlm(CLI *c, SERVICE_OPTIONS *opt) { ntlm2_txt=str_dup(line+25); else if(is_prefix(line, "Content-Length: ")) { content_length=strtol(line+16, &tmpstr, 10); + if(tmpstr>line+16) /* found some digits */ + while(*tmpstr && isspace(*tmpstr)) + ++tmpstr; if(tmpstr==line+16 || *tmpstr || content_length<0) { s_log(LOG_ERR, "Proxy-Authenticate: Invalid Content-Length"); str_free(line);
You may also try stunnel 5.18b1: https://www.stunnel.org/downloads.html
Mike
On 13.05.2015 13:38, Marcin Gryszkalis wrote:
Hi,
I noticed that parsing of HTTP header fields is not robust enough and not RFC compliant - and that way it casues incompatibility with Microsoft TMG proxy with NTLM authentication.
The symptom is "Proxy-Authenticate: Invalid Content-Length" message while the header received is "Content-Length: 0 " <- note trailing spaces.
The responsible piece of code is in protocol.c: if(tmpstr==line+16 || *tmpstr || content_length<0) {
(tmpstr contains trailing spaces in this case).
According to RFC 7230 trailing space is allowed and should be discarded by parser:
A field value might be preceded and/or followed by optional whitespace (OWS); a single SP preceding the field-value is preferred for consistent readability by humans. The field value does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace octet of the field value ought to be excluded by parsers when extracting the field value from a header field.
best regards