You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Ken Giusti (JIRA)" <ji...@apache.org> on 2012/12/11 20:43:22 UTC
[jira] [Comment Edited] (PROTON-161) SSL impl does not allow
verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529256#comment-13529256 ]
Ken Giusti edited comment on PROTON-161 at 12/11/12 7:43 PM:
-------------------------------------------------------------
Affan,
As we used to say: "Busted!" You're entirely correct: the current patch only checks the CommonName fields. I do need to add support for properly checking the subjectAltName fields as per rfc2818. The problem is I'm having a hard time finding a way of getting at that information in the certificate. The OpenSSL documentation is very sparse on the subject, and the only code examples I can find are internal to OpenSSL or use API calls that won't be supported on older platforms. I'm still looking, but until I can get something that works I'd recommend we go with the CommonName approach at minimum. While it may be deprecated, it plugs a security hole.
And for 2): hostname check is only performed if set_peer_hostname() is called. So if you use VERIFY_PEER, but don't call set_peer_hostname(), then the certificate will be validated, and, if valid, the connection is permitted without performing a host name check.
was (Author: kgiusti):
Affan,
As we used to say: "Busted!" You're entirely correct: the current patch only checks the CommonName fields. I do need to add support for properly checking the subjectAltName fields as per rfc2818. The problem is I'm having a hard time finding a way of getting at that information in the certificate. The OpenSSL documentation is very sparse on the subject, and the only code examples I can find are internal to OpenSSL or use API calls that won't be supported on older platforms. I'm still looking, but until I can get something that works I'd recommend we go with the CommonName approach at minimum. While it may be deprecated, it plugs a security hole.
> 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