[
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
