[ 
https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528527#comment-13528527
 ] 

Affan Dar commented on PROTON-161:
----------------------------------

A couple of quick comments:

1) The HTTP/TLS verification uses subjectAltName if present in the cert instead 
of commonName:

http://tools.ietf.org/html/rfc2818#section-3.1

"If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead."

In the code I see that we are using the commonName itself. I think it would be 
better to follow the same logic as HTTPS for this.

2) Is it possible to add an option to disable hostname validation? We could set 
the pn_ssl_verify_mode_t to PN_SSL_ANONYMOUS_PEER but that would skip even the 
cert validation I think. Btw if we expect the wildcard support to land soon 
then this can become a subset of that (*).

                
> SSL impl does not allow verification of the peer's identity
> -----------------------------------------------------------
>
>                 Key: PROTON-161
>                 URL: https://issues.apache.org/jira/browse/PROTON-161
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.3
>            Reporter: Ken Giusti
>            Assignee: Ken Giusti
>            Priority: Blocker
>
> The current SSL implementation validates the peer's certificate, and will not 
> permit the connection to come up if the certificate is invalid.
> However - it does not provide a way to check if the peer's identity as 
> provided in the certificate is the expected identity (eg, the same hostname 
> used to set up the TCP connection).  While a certificate may be valid (that 
> is, signed by a CA trusted by the client), it may not belong to the intended 
> destination.
> RFC2818 explains how this should be done - see section 3.1 Server Identity. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to