[jira] [Comment Edited] (TS-3138) Implement TLS False Start

["Wei Sun (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177827#comment-14177827 ] 

Wei Sun edited comment on TS-3138 at 10/21/14 2:00 AM:
-------------------------------------------------------

[~briang], fyi, I verified tls false start in the past for full handshake with ats-4.x + Firefox 29.0.1, seems ats is able to handle that. Please see tcpdump screenshots in the attachment.
{{enabled_tls_falsestart_ats.png}}: #479 shows that client sends out application data immediately after its “Change Cipher Spec”.



was (Author: sunwei):
[~briang], fyi, I verified tls false start in the past for full handshake with ats-4.x + Firefox 29.0.1, seems ats works fine. Please see tcpdump screenshots in the attachment.
{{enabled_tls_falsestart_ats.png}}: #479 shows that client sends out application data immediately after its “Change Cipher Spec”.


> Implement TLS False Start
> -------------------------
>
>                 Key: TS-3138
>                 URL: https://issues.apache.org/jira/browse/TS-3138
>             Project: Traffic Server
>          Issue Type: New Feature
>          Components: Core, SSL
>            Reporter: Brian Geffon
>            Assignee: Brian Geffon
>             Fix For: 5.2.0
>
>
> TLS false start can really reduce latency by allowing data to be transmitted before the CipherChange has been completed. For more information see: 
> http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_FALSE_START and http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
> We need to 1) verify that Traffic Server correctly reads data that was transmitted as false start before the hand shake is "officially complete." and 2) if it's not then determine why the read is not happening earlier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)