[asterisk-bugs] [JIRA] (ASTERISK-28657) SIPS TLS connection fails when session ticket extension is used
Kevin Harwell (JIRA)
noreply at issues.asterisk.org
Wed Dec 18 18:17:32 CST 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-28657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=249123#comment-249123 ]
Kevin Harwell commented on ASTERISK-28657:
------------------------------------------
Hrm, not really sure what could be the problem here. It seems pretty straight forward, but I am unable to replicate. I installed Debian 9, and installed the same version of openssl just to make sure that wasn't it:
{noformat}
$ openssl version
OpenSSL 1.1.0k 28 May 2019
{noformat}
I also used your _sip.conf_ file. As far as the {{tlsverifyclient}} configuration option goes that is not used, and is ignored by chan_sip so I don't think that could be it.
And attempting to replicate using pjsip causes a different error down in pjproject, which I suspect has more to do with test client.
> 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)
More information about the asterisk-bugs
mailing list