[jira] [Commented] (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=13530496#comment-13530496 ] Ken Giusti commented on PROTON-161: --- Update: added SubjectAltName checking, certificate wildcard, removed the pattern api. See patch: https://reviews.apache.org/r/8449/ -K > 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
[jira] [Commented] (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 commented on PROTON-161: --- 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
[jira] [Commented] (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=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
[jira] [Commented] (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=13528351#comment-13528351 ] Ken Giusti commented on PROTON-161: --- Posted a candidate fix to reviewboard: https://reviews.apache.org/r/8449/ At this time, only exact string match is supported. Need to add wildcard pattern matching, but that could be added in a later patch. > 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
[jira] [Commented] (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=13506847#comment-13506847 ] Ken Giusti commented on PROTON-161: --- Here's something to consider: The TLS handshake allows the client to send to the server the hostname the client is attempting to connect to at the start of the handshaking process (Server Name Indication - RFC3546). My understanding is that this hostname is also the name the client should use when checking the name given in the server's certificate. Since we can't advertise a wildcarded hostname, I'd like to supply two separate configuration options for hostname verification: 1) allow the configuration of the expected peer hostname for a given SSL connection. This name will be sent by client connections when the handshake starts. 2) optionally, specify a match pattern to use when verifying the received peer certificate. If only 1 is applied (2 not used - no pattern specified), then the default verification behavior would be to perform an exact match of the hostname against the name supplied in the peer's certificate. if 2 is applied, then the certificate match is performed using the given pattern/hostname string, perhaps restricted by some flag values. Neither applied - no hostname verification (risky). Perhaps something like: pn_ssl_set_peer_hostname( pn_ssl_t *, const char *) // send this exact string as SNI during handshake pn_ssl_set_peer_hostname_match( pn_ssl_t *, const char *pattern, enum match_flags) match_flags would be something like: MATCH_EXACT - default, perform simple exact string compare MATCH_WILDCARD - a "*" in the pattern string performs a greedy match: "*.bar.com" allows "foo.bar.com", "foo.boo.bar.com" MATCH_DNS_WILDCARD - a "*" will not match ".", so "*.bar.com" will match "foo.bar.com", but not "foo.boo.bar.com"... others? Opinions? > 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
[jira] [Commented] (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=13504844#comment-13504844 ] Affan Dar commented on PROTON-161: -- I think that works fine. I.e, these three modes for hostname verification should cover most of the cases IMO: none, exact (subjectAltName or commonName must match the destination hostname) or custom (user provides hostname to match, hostname might contain wildcards). > 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
[jira] [Commented] (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=13504688#comment-13504688 ] Rafael H. Schloming commented on PROTON-161: What amount of plug-ability to you anticipate needing here? I'd like to be able to provide up front configuration to cover the majority of scenarios here, not only for convenience, but also because there's a significant technical obstacle to doing callbacks across language boundaries. Do you think wildcard matching would cover 90% of the cases? Are there significant other scenarios we could/should account for up front? > 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
[jira] [Commented] (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=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
