How to send alert in handshake?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How to send alert in handshake?

Felipe Gasper-2
RFC 3546, in describing the SNI extension, recommends that servers send a warning to clients that request an unknown server name. (Page 9)

I’d like to implement that warning .. could someone please point me to which API functions expose this ability?

Thank you!

-Felipe Gasper
Mississauga, ON
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to send alert in handshake?

OpenSSL - User mailing list
As in sending a non-fatal alert?  There's no API to do that.  And it probably wouldn't work anyway, as most runtimes treat any alert as fatal.

Your best bet is to implement the right callback (depends on which version of openssl you are using) and return an error if the SNI isn't one of your allowed values.

On 6/27/18, 8:45 AM, "Felipe Gasper" <[hidden email]> wrote:

    RFC 3546, in describing the SNI extension, recommends that servers send a warning to clients that request an unknown server name. (Page 9)
   
    I’d like to implement that warning .. could someone please point me to which API functions expose this ability?
   
    Thank you!
   
    -Felipe Gasper
    Mississauga, ON
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
   

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to send alert in handshake?

Matt Caswell-2
In reply to this post by Felipe Gasper-2


On 27/06/18 12:41, Felipe Gasper wrote:
> RFC 3546, in describing the SNI extension, recommends that servers send a warning to clients that request an unknown server name. (Page 9)
>
> I’d like to implement that warning .. could someone please point me to which API functions expose this ability?

In order to implement SNI you need an SNI callback which can be set with
this function:

 long SSL_CTX_set_tlsext_servername_callback(SSL_CTX *ctx,
                                   int (*cb)(SSL *, int *, void *));

It is (briefly) documented in 1.1.1 (but not earlier versions - although
it exists in those versions):

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_tlsext_servername_callback.html

The documentation seems to be missing some vital information though -
like what the arguments to the callback mean and what the return value does!

The callback should return:

SSL_TLSEXT_ERR_OK, if it successfully processed the SNI
SSL_TLSEXT_ERR_ALERT_WARNING, to send a warning alert back
SSL_TLSEXT_ERR_ALERT_FATAL, to send a fatal alert back
SSL_TLSEXT_ERR_NOACK, to continue without acknowledging the SNI at all

The alert, if sent, will default to SSL_AD_UNRECOGNIZED_NAME but you can
fill in the second "int *" argument to the callback with some other
alert value if you wish.

From the callback you can determine what the requested servername was by
calling SSL_get_servername().

Note though that RFC 3546 that you reference is obsolete. It was
obsoleted by RFC 4366, which itself was obsoleted by RFC 6066. That last
RFC has this to say about fatal vs warning alerts:

   If the server understood the ClientHello extension but
   does not recognize the server name, the server SHOULD take one of two
   actions: either abort the handshake by sending a fatal-level
   unrecognized_name(112) alert or continue the handshake.  It is NOT
   RECOMMENDED to send a warning-level unrecognized_name(112) alert,
   because the client's behavior in response to warning-level alerts is
   unpredictable.  If there is a mismatch between the server name used
   by the client application and the server name of the credential
   chosen by the server, this mismatch will become apparent when the
   client application performs the server endpoint identification, at
   which point the client application will have to decide whether to
   proceed with the communication.  TLS implementations are encouraged
   to make information available to application callers about warning-
   level alerts that were received or sent during a TLS handshake.  Such
   information can be useful for diagnostic purposes.


Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to send alert in handshake?

Viktor Dukhovni


> On Jun 27, 2018, at 9:12 AM, Matt Caswell <[hidden email]> wrote:
>
> Note though that RFC 3546 that you reference is obsolete. It was
> obsoleted by RFC 4366, which itself was obsoleted by RFC 6066. That last
> RFC has this to say about fatal vs warning alerts:
>
>   If the server understood the ClientHello extension but
>   does not recognize the server name, the server SHOULD take one of two
>   actions: either abort the handshake by sending a fatal-level
>   unrecognized_name(112) alert or continue the handshake.  It is NOT
>   RECOMMENDED to send a warning-level unrecognized_name(112) alert,
>   because the client's behavior in response to warning-level alerts is
>   unpredictable.  If there is a mismatch between the server name used
>   by the client application and the server name of the credential
>   chosen by the server, this mismatch will become apparent when the
>   client application performs the server endpoint identification, at
>   which point the client application will have to decide whether to
>   proceed with the communication.

What this means is that you really should NOT send alerts, and either
select a matching certificate chain, or else let the server proceed
with the default certificate chain.  Don't abort the connection just
because the SNI did not match.  Some clients accept more than one
server name, but can only send one name in the SNI.  The default
chain may also be acceptable.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to send alert in handshake?

Angus Robertson - Magenta Systems Ltd
In reply to this post by Matt Caswell-2
> In order to implement SNI you need an SNI callback
> The callback should return:
>
> SSL_TLSEXT_ERR_OK, if it successfully processed the SNI
> SSL_TLSEXT_ERR_ALERT_WARNING, to send a warning alert back
> SSL_TLSEXT_ERR_ALERT_FATAL, to send a fatal alert back
> SSL_TLSEXT_ERR_NOACK, to continue without acknowledging the SNI
> at all

Our SSL library used to return SSL_TLSEXT_ERR_ALERT_WARNING if no name
match was found, until we discovered that Java SSL treats this as a
fatal error when we changed to OK.  

But it did not seem to cause a problem with any browsers or OpenSSL
clients, which I assume ignore it.  

What would SSL_alert_type_string return in the client?  

Angus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users