[
https://issues.apache.org/jira/browse/TS-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520198#comment-14520198
]
Dave Thompson commented on TS-3570:
-----------------------------------
I didn't see expiration time check done at ATS level, because as it turns out,
it isn't, but rather handled at the openssl level.
Further, ATS does have a config property proxy.config.ssl.session_cache.timeout
value, which if set I see the value I see that it gets propagated down to SSL
layer, and to the client.
openssl s_client -connect `hostname`:4443 -tls1
will report "TLS session ticket lifetime hint" which is set to what the ATS TLS
server config property is set to.
Ok, so let's make this ticket a nevermind.
> Need to implement TLS server side Session ID and Session Ticket expiration
> ---------------------------------------------------------------------------
>
> Key: TS-3570
> URL: https://issues.apache.org/jira/browse/TS-3570
> Project: Traffic Server
> Issue Type: Bug
> Components: Security, SSL
> Reporter: Dave Thompson
> Assignee: Dave Thompson
>
> It appears that ATS does not track session ID/session ticket expiration.
> This is the responsibility of the TLS server side implementation to not allow
> resumption of prior negotiated credentials after expiration. Because
> time/expiration is not tracked, the upper limit as to how long a bad guy has
> to compromise prior negotiated keys, may only be limited by cache eviction
> from heavy traffic flow. This situation effectively removes various
> factoring time limits, e.g. TLS FREAK attacks and others.
> General TLS guidelines (e.g. RFC 5246, Sec F.1.4, and predecessors) suggest
> upper limits of 24 hours. NIST has an independent set of guidelines that may
> be more tailored to cipher suites. Actual time limit should be out of scope
> of implementation, and handled by the configuration, however ATS, should
> honor operator set time limit.
> First pass would not allow session re-use after time expired of initial
> negotiations. Better implementation, would not only not allow, but would
> zero-out session credentials as soon as expiration time occurs, in stored
> master/session key.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
