cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: non-blocking ssl connections with PolarSSL

From: Paul Bakker <paul_curl_at_brainspark.nl>
Date: Thu, 19 Apr 2012 11:34:42 +0200

On 6-4-2012 15:13, Daniel Stenberg wrote:
> On Thu, 5 Apr 2012, Daniel Stenberg wrote:
>
>> We should now work on fixing the test cases that fail (311 and 313).
>> I noticed that we had two test failures already before your patch and
>> I get two now after the patch is applied as well!
>
> Update:
>
> I found and fixed the test 313 failure.
>
> I can't but to think that the test 311 failure is a flaw in PolarSSL
> itself so I submitted this bug report:
>
> http://polarssl.org/trac/ticket/56
>
The failure in test 311 is caused by the fact that PolarSSL accepts a
certificate where the CN is correct but the subjectAltName is not. And
the test expects a rejection because the CN should be ignored if there
is a subjectAltName in the certificate.

This seems to be a 'HTTP over TLS'-specific error.

In RFC 2818 (HTTP over TLS) it is stated that this behaviour is as such.
RFC 5280, governing the generic X509 handling, does not state this
behaviour and desribes that the CN is still a valid name to check. The
SSL/TLS guidelines themselves do not discuss this handling any further.

But there may be another RFC that governs this that I have missed. Can
anybody else confirm or counter that this is HTTP over TLS specific and
not SSL/TLS generic?

So proper behaviour looks to be to add a verify_callback in the cURL
PolarSSL wrapper code to check the certificate for the conditions in the
RFC2818 guidelines. If extra metadata for the certificate is needed for
this, please let me know, so I can add it.

If anybody has another solution to propose, please let me know as well!

Best regards,
Paul Bakker
PolarSSL maintainer
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-04-19