Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS session tickets broken in ATS 7 #1943

Closed
mlibbey opened this issue May 19, 2017 · 6 comments
Closed

TLS session tickets broken in ATS 7 #1943

mlibbey opened this issue May 19, 2017 · 6 comments
Assignees
Labels
Milestone

Comments

@mlibbey
Copy link
Contributor

mlibbey commented May 19, 2017

In ATS 6, TLS session tickets worked (ticket_key_name in ssl_multicert). It appear broken in 7.0 and 7.1.

Here's 2 machines with ATS6.1:

$ d="example.com"; m1=$(dig +short firstmachine.example.com);m2=$(dig +short secondmachine.example.com);echo | openssl s_client -servername $d -connect $m1:443 -sess_out mySession| grep read; md5 mySession; echo |openssl s_client -servername $d -connect $m2:443 -sess_in mySession| grep read; md5 mySession;
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3
verify return:1
depth=0 jurisdictionC = US, jurisdictionST = California, businessCategory = Private Organization, serialNumber = C123456, C = US, postalCode = 95014, ST = California, L = Cupertino, street = 10 Main St, O = NewCo Inc., OU = GNCS, CN = example.com
verify return:1
DONE
SSL handshake has read 3822 bytes and written 455 bytes
MD5 (mySession) = 8eb4c5a3f9e2c11f5425dc7c41f3dc45
DONE
SSL handshake has read 142 bytes and written 620 bytes
MD5 (mySession) = 8eb4c5a3f9e2c11f5425dc7c41f3dc45

(the thing to look for is the "read 142 bytes" -- that its much smaller in the 2nd response.

In ATS 7.0 and 7.1

$ d="example.com"; m1=$(dig +short firstmachine.example.com);m2=$(dig +short secondmachine.example.com);echo | openssl s_client -servername $d -connect $m1:443 -sess_out mySession| grep read; md5 mySession; echo |openssl s_client -servername $d -connect $m2:443 -sess_in mySession| grep read; md5 mySession;
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3
verify return:1
depth=0 jurisdictionC = US, jurisdictionST = California, businessCategory = Private Organization, serialNumber = C123456, C = US, postalCode = 95014, ST = California, L = Cupertino, street = 10 Main St, O = NewCo Inc., OU = GNCS, CN = example.com
verify return:1
DONE
SSL handshake has read 3826 bytes and written 455 bytes
MD5 (mySession) = 551e4a54d33c4877e3c9bbed4f70d9e4
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3
verify return:1
depth=0 jurisdictionC = US, jurisdictionST = California, businessCategory = Private Organization, serialNumber = C0806592, C = US, postalCode = 95014, ST = California, L = Cupertino, street = 10 Main St, O = NewCo Inc., OU = GNCS, CN = example.com
verify return:1
DONE
SSL handshake has read 3826 bytes and written 695 bytes
MD5 (mySession) = 551e4a54d33c4877e3c9bbed4f70d9e4

The read bytes is equal for both the 1st and 2nd machine (and details about the cert are written out twice).

@mlibbey mlibbey added this to the 7.1.0 milestone May 19, 2017
@persiaAziz-zz persiaAziz-zz self-assigned this May 19, 2017
@shinrich
Copy link
Member

I assume that you are sharing ticket keys between firstmachine and secondmachine? Can you share your ssl_multicert.config file? Persia is having a hard time reproducing the issue.

@mlibbey
Copy link
Contributor Author

mlibbey commented May 19, 2017

Turns out the behavior has changed with ATS 7. The session ticket is no longer controlled by ssl_multicert. Instead, its in records.config:
CONFIG proxy.config.ssl.server.ticket_key.filename STRING ssl_ticket.key

We need to update our documentation for this.

@persiaAziz-zz
Copy link
Contributor

Yes. I will remove the field for ticket key from ssl_multicert and update the docs. The documentation on proxy.config.ssl.server.ticket_key.filename is in
https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html?highlight=records

@mlibbey
Copy link
Contributor Author

mlibbey commented May 19, 2017

Oh -- this is a pretty big pain to rotate keys now -- now, you have to change the filename string in records.config to rotate. Before, ssl_multicert would get reloaded pretty frequently, and as a result, just changing the file contents of the ticket would get picked up. Now, if you change the file content and reload configs, ATS won't realize the ticket file has changed, and thus won't reload.

@zwoop
Copy link
Contributor

zwoop commented May 23, 2017

@mlibbey Can you file a Github issue on this? Or should we keep / change this Issue to an RFE for better config reload ?

@bryancall bryancall added the TLS label May 23, 2017
@persiaAziz-zz
Copy link
Contributor

Already created @zwoop #1962

PR 1970 has the fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants