[asterisk-bugs] [JIRA] (ASTERISK-28657) SIPS TLS connection fails when session ticket extension is used

[Marcel Dischinger (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249125#comment-249125 ] 

Marcel Dischinger commented on ASTERISK-28657:
----------------------------------------------

Ah, there might be an explanation. I patched chan_sip.c to use tlsverifyclient, which works for me just fine (the code below omits the check of the return value of ast_tls_read_conf for brevity).
{noformat}
if (!strcasecmp(v->name, "tlsverifyclient")) {
-			ast_log(LOG_WARNING, "Ignoring unsupported option 'tlsverifyclient'\n");
-			continue;
+                       ast_tls_read_conf(&default_tls_cfg, &sip_tls_desc, v->name, v->value);
}
{noformat}

But this would then mean that there is in fact no problem in Asterisk (at least not in the setup I described), but the patch I did had side effects.

Nevertheless, I learned from this problem that it is rather easy to mess up OpenSSL usage. So it may be a safeguard to set up the session ID context just to avoid future problems.

> SIPS TLS connection fails when session ticket extension is used
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-28657
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28657
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.21.0
>         Environment: Tested with LTS certified, but according to the code this problem should apply to all newer versions as well.
> Using Debian Stretch and the dependencies used there (e.g., OpenSSL 1.1.0k).
> Using Asterisk with SIPS.
>            Reporter: Marcel Dischinger
>            Assignee: Marcel Dischinger
>         Attachments: sip.conf, tls_sessionticket_test.pl, tlstest.pcap
>
>
> The TLS implementation of Asterisk using OpenSSL has a flaw that results in OpenSSL bailing with an internal error when a client tries to use session-reuse with the session ticket extension. This happens when Asterisk is used as a server for SIPS connections, i.e., SIPS-clients set up a TLS connection to Asterisk.
> h2. How does this work?
> # Client contacts Asterisk to set up a TLS connection
> # Certificates are exchanged, keys are derived
> # TLS session established
> # Asterisk sends a TLS NewSessionTicket extension message (see RFC 5077) to the client
> # TLS session is closed
> # Client starts a new TLS session, sends the session ticket from 4. with the ClientHello
> # Asterisk/OpenSSL should use this ticket to establish a new TLS session reusing the exchanged keys from the previous session.
> h2. Bug analysis
> From the asterisk log:
> {quote}ERROR tcptls.c: Problem setting up ssl connection: error:00000001:lib(0):func(0):reason(1), Internal SSL error
> WARNING tcptls.c: FILE * open {quote}
> Reason for this is described in the warning for ssl_ctx_set_session_id_context in OpenSSL (see, e.g.,
> https://linux.die.net/man/3/ssl_ctx_set_session_id_context): session id context is not set.
> h2. Bugfix
> To fix this, this context has to be set in  tcptls.c:__ssl_setup, e.g., directly before setting up the TLS options, right after setting up the general SSL-contect. There, add the following line:
> SSL_CTX_set_session_id_context(cfg->ssl_ctx, (const unsigned char *) "asterisk", 8);
> As an alternative, you can also disable the usage of RFC5077 by setting the SSL option SSL_OP_NO_TICKET. With this, Asterisk will no longer send the NewSessionTicket extension message, hence for the second TLS setup a SessionTicket is not included in the ClientHello.



--
This message was sent by Atlassian JIRA
(v6.2#6252)