You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2015/05/13 15:31:00 UTC

[jira] [Comment Edited] (TS-3598) Should we add an option to refuse non-SNI negotiated TLS connections

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

Leif Hedstrom edited comment on TS-3598 at 5/13/15 1:30 PM:
------------------------------------------------------------

One thought, *if* there is no SNI negotiated, and there is no dest_ip that matches, maybe then we should fail the handshake? Is that how it's expected to work anyways? If so we probably just update the docs, and close this.


was (Author: zwoop):
One though, *if* there is no SNI negotiated, and there is no dest_ip that matches, maybe then we should fail the handshake? Is that how it's expected to work anyways? If so we probably just update the docs, and close this.

> Should we add an option to refuse non-SNI negotiated TLS connections
> --------------------------------------------------------------------
>
>                 Key: TS-3598
>                 URL: https://issues.apache.org/jira/browse/TS-3598
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: SSL
>            Reporter: Leif Hedstrom
>
> I'm not 100% certain how this interoperates with all the various SSL and TLS versions, but, we might want to consider adding an option to refuse non-SNI handshakes completely.
> The rationale is this:
> If we have multiple sites, as configured in ssl_multicert.config, but the box does not have unique IPs for each such cert, then the current behavior is undesirable (maybe even insecure?). E.g. the setup would be
> {code}
> dest_ip=* ssl_cert_name=cert1.crt ssl_key_name=key1.key
> dest_ip=* ssl_cert_name=cert2.crt ssl_key_name=key2.key
> dest_ip=* ssl_cert_name=cert3.crt ssl_key_name=key2.key
> {code}
> In the case of a non-SNI connection, the first certificate will now always be presented. This is likely not to be "secure", in that browser will either reject or give nasty errors / warnings about the wrong CN in the certificate.
> In this case, having an option to say "refuse non-SNI handshakes" might be more desirable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)