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

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

A quick thought/requirement on the user model for the implementation: it would 
be great if the hostname verification is pluggable so apps can skip it 
completely if required or do a more lax verification. E.g. accept all 
certificates with an subjectAltName that has a suffix *.domain.com.

I.e., allow this part of the RFC2818, sec 3.1:

"If the client has external information as to the expected identity of
  the server, the hostname check MAY be omitted. (For instance, a
  client may be connecting to a machine whose address and hostname are
  dynamic but the client knows the certificate that the server will
  present.) In such cases, it is important to narrow the scope of
  acceptable certificates as much as possible in order to prevent man
  in the middle attacks.  In special cases, it may be appropriate for
  the client to simply ignore the server's identity, but it must be
  understood that this leaves the connection open to active attack."


                
> 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