trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reindl Harald <h.rei...@thelounge.net>
Subject Re: ssl_ticket_enabled=0 don't work
Date Fri, 30 Jan 2015 02:05:43 GMT
nothing in "diags.log"
with our without the "traffic_line -x"

anaways, i think this should be easy to reprodcue by just call 
https://www.ssllabs.com/ssltest/ and the same for "SSL 2 handshake 
compatibility No" which reduces client compatibility

[root@proxy:/var/log/trafficserver]$ locate ssl_multicert.config
/etc/trafficserver/ssl_multicert.config
[root@proxy:/var/log/trafficserver]$ touch 
/etc/trafficserver/ssl_multicert.config
[root@proxy:/var/log/trafficserver]$ traffic_line -s 
proxy.config.diags.debug.tags -v ssl
Set proxy.config.diags.debug.tags
[root@proxy:/var/log/trafficserver]$ traffic_line -s 
proxy.config.diags.debug.enabled -v 1
Set proxy.config.diags.debug.enabled
[root@proxy:/var/log/trafficserver]$ traffic_line -x
[root@proxy:/var/log/trafficserver]$ cat diags.log
[Jan 30 03:00:01.382] Server {0x2b4de5771700} NOTE: updated diags config
[Jan 30 03:00:10.386] Server {0x2b4de5771700} NOTE: updated diags config

Am 30.01.2015 um 01:57 schrieb Leif Hedstrom:
> Note that changing records.config settings via traffic_line doesn't require a traffic_line
-x. I wonder if you ended up reloading the records.config from disk before it was saved out?
>
> Try again but without the last -x invocation ?
>
>> On Jan 29, 2015, at 5:23 PM, James Peach <jpeach@apache.org> wrote:
>>
>>
>>> On Jan 29, 2015, at 4:14 PM, Reindl Harald <h.reindl@thelounge.net> wrote:
>>>
>>>
>>> Am 29.01.2015 um 20:25 schrieb James Peach:
>>>>> On Jan 29, 2015, at 10:29 AM, Reindl Harald <h.reindl@thelounge.net>
wrote:
>>>>>
>>>>>
>>>>> [root@localhost:~]$ cat /etc/trafficserver/ssl_multicert.config
>>>>> ssl_cert_name=thelounge.net.pem ssl_ca_name=godaddy_ca_sha256.crt ssl_ticket_enabled=0
>>>>>
>>>>> https://www.ssllabs.com/ssltest/
>>>>> Session resumption (caching)    Yes
>>>>> Session resumption (tickets)    Yes
>>>>> SSL 2 handshake compatibility    No
>>>>
>>>> First, what version of OpenSSL is this? We try to set SSL_OP_NO_TICKET, which
I believe was added in OpenSSL 0.9.9. Maybe httpd uses a different technique to disable session
tickets.
>>>
>>> Fedora 20
>>> openssl-1.0.1e-41.fc20
>>>
>>>> Can you turn on "ssl" debug logging? With ssl_ticket_enabled=0 you should
see a message like "ssl session ticket is disabled" ...
>>>
>>> not sure how to do that
>>
>> To do this with a running process:
>>
>> traffic_line -s proxy.config.diags.debug.tags -v ssl
>> traffic_line -s proxy.config.diags.debug.enabled -v 1
>> traffic_line -x
>>
>> Depending on your config, you will most likely see the messages in diags.log
>>
>>> the only reachable server for ssllabs ist the production one
>>> testing environments are not reachable from outside
>>>
>>>>> (the ssl 2 handshake compatibility needs to be fixed too for some client
like "ab" the apache benchmark tool)
>>>
>>> BTW: that annoys me for years now - "ab" supports SNI fine but not with ATS
>>
>> I don't know what the problem is with "ab", but there is config for allowing various
SSL protocol versions:
>>
>> $ traffic_line -m proxy.config.ssl.*v[0-9_]
>> proxy.config.ssl.SSLv2 0
>> proxy.config.ssl.SSLv3 0
>> proxy.config.ssl.TLSv1 1
>> proxy.config.ssl.TLSv1_1 1
>> proxy.config.ssl.TLSv1_2 1
>> proxy.config.ssl.client.SSLv2 0
>> proxy.config.ssl.client.SSLv3 1
>> proxy.config.ssl.client.TLSv1 1
>> proxy.config.ssl.client.TLSv1_1 1
>> proxy.config.ssl.client.TLSv1_2 1
>>
>>>
>>>>> _______________________________
>>>>>
>>>>> the today release of httpd introduces an option for that and it's description
says for me "no i do not want to restart services daily"
>>>>>
>>>>> with Off https://www.ssllabs.com/ssltest/ says correctly
>>>>>
>>>>> Session resumption (caching)    Yes
>>>>> Session resumption (tickets)     No
>>>>>
>>>>> mod_ssl: New directive SSLSessionTickets (On|Off). The directive controls
the use of TLS session tickets (RFC 5077), default value is "On" (unchanged behavior). Session
ticket creation uses a random key created during web server startup and recreated during restarts.
No other key recreation mechanism is available currently. Therefore using session tickets
without restarting the web server with an appropriate frequency (e.g. daily) compromises perfect
forward secrecy. [Rainer Jung]



Mime
View raw message