{"action":"created","issue":{"url":"https://api.github.com/repos/openssl/openssl/issues/6647","repository_url":"https://api.github.com/repos/openssl/openssl","labels_url":"https://api.github.com/repos/openssl/openssl/issues/6647/labels{/name}","comments_url":"https://api.github.com/repos/openssl/openssl/issues/6647/comments","events_url":"https://api.github.com/repos/openssl/openssl/issues/6647/events","html_url":"https://github.com/openssl/openssl/issues/6647","id":338234812,"node_id":"MDU6SXNzdWUzMzgyMzQ4MTI=","number":6647,"title":"OpenSSL server is 0-RTT intolerant by default","user":{"login":"tomato42","id":618246,"node_id":"MDQ6VXNlcjYxODI0Ng==","avatar_url":"https://avatars1.githubusercontent.com/u/618246?v=4","gravatar_id":"","url":"https://api.github.com/users/tomato42","html_url":"https://github.com/tomato42","followers_url":"https://api.github.com/users/tomato42/followers","following_url":"https://api.github.com/users/tomato42/following{/other_user}","gists_url":"https://api.github.com/users/tomato42/gists{/gist_id}","starred_url":"https://api.github.com/users/tomato42/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tomato42/subscriptions","organizations_url":"https://api.github.com/users/tomato42/orgs","repos_url":"https://api.github.com/users/tomato42/repos","events_url":"https://api.github.com/users/tomato42/events{/privacy}","received_events_url":"https://api.github.com/users/tomato42/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-07-04T11:15:31Z","updated_at":"2018-07-04T15:59:24Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"When server is configured to support TLS 1.3 (358ffa05cd3a0 default), it will not handle a 0-RTT resume by a client gracefully - the connection will be aborted after server Finished with an `unexpected_message` alert.\r\n\r\nthis is in contrast to the draft-28 that server [MUST](https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58) either:\r\n * \"Ignore the extension and return a regular 1-RTT response.\"...\r\n * \"Request that the client send another ClientHello by responding with a HelloRetryRequest.\"...\r\n * \"Return its own \"early_data\" extension in EncryptedExtensions\"...\r\n\r\nNot following that requirement will cause the server to become intolerant to 0-RTT handshakes, after the 0-RTT support was disabled.\r\n\r\nNote: here I mean just the ability to tolerate an 0-RTT handshake, not actually using the encrypted data.\r\n\r\nNote: there are `-max_early_data` and `-early_data` switches to s_server, but I don't think enabling 0-RTT _support_ should be required to make implementation 0-RTT _tolerant_\r\n\r\n   <details><summary>reproducer</summary><p>\r\n\r\n```\r\nopenssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch\r\nopenssl s_server -key localhost.key -cert localhost.crt -www 2>server.err >server.out &\r\nopenssl_pid=$!\r\ngit clone https://github.com/tomato42/tlsfuzzer\r\npushd tlsfuzzer\r\n# won't be needed after tlsfuzzer#423 is merged\r\ngit checkout 0rtt-garbage-resumption\r\ngit clone https://github.com/tomato42/tlslite-ng .tlslite-ng\r\nln -s .tlslite-ng/tlslite tlslite\r\ngit clone https://github.com/warner/python-ecdsa .python-ecdsa\r\nln -s .python-ecdsa/ecdsa ecdsa\r\nPYTHONPATH=. python scripts/test-tls13-0rtt-garbage.py\r\npopd\r\nkill $openssl_pid\r\n```\r\n\r\nThe script supports a `--num-bytes` option allowing the script to change the amount of fake data sent as early data.\r\n\r\n   </p></details>\r\n\r\n   <details><summary>tlsfuzzer output</summary><p>\r\n\r\n```\r\nsanity ...\r\nOK\r\n\r\nhandshake with invalid PSK ...\r\nOK\r\n\r\nhandshake with invalid 0-RTT ...\r\nError encountered while processing node <tlsfuzzer.expect.ExpectNewSessionTicket object at 0x7f3a48d7a550> (child: <tlsfuzzer.expect.ExpectNewSessionTicket object at 0x7f3a48d7a550>) with last message being: <tlslite.messages.Message object at 0x7f3a48d7acd0>\r\nError while processing\r\nTraceback (most recent call last):\r\n  File \"scripts/test-tls13-0rtt-garbage.py\", line 262, in main\r\n    runner.run()\r\n  File \"/home/hkario/dev/tlsfuzzer/tlsfuzzer/runner.py\", line 210, in run\r\n    RecordHeader2)))\r\nAssertionError: Unexpected message from peer: Alert(fatal, unexpected_message)\r\n\r\nsanity ...\r\nOK\r\n\r\nBasic check if TLS 1.3 server can handle 0-RTT handshake\r\nVerify that the server can handle a 0-RTT handshake from client\r\neven if (or rather, especially if) it doesn't support 0-RTT.\r\n\r\nversion: 1\r\n\r\nTest end\r\nsuccessful: 3\r\nfailed: 1\r\n  'handshake with invalid 0-RTT'\r\n```\r\n\r\n   </p></details>\r\n\r\n   <details><summary>openssl output</summary><p>\r\n\r\n```\r\nUsing default temp DH parameters\r\nACCEPT\r\n140180740319040:error:142140A4:SSL routines:early_data_count_ok:too much early data:ssl/record/ssl3_record.c:129:\r\n```\r\n\r\n   </p></details>"},"comment":{"url":"https://api.github.com/repos/openssl/openssl/issues/comments/402516544","html_url":"https://github.com/openssl/openssl/issues/6647#issuecomment-402516544","issue_url":"https://api.github.com/repos/openssl/openssl/issues/6647","id":402516544,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMjUxNjU0NA==","user":{"login":"kaduk","id":1894506,"node_id":"MDQ6VXNlcjE4OTQ1MDY=","avatar_url":"https://avatars1.githubusercontent.com/u/1894506?v=4","gravatar_id":"","url":"https://api.github.com/users/kaduk","html_url":"https://github.com/kaduk","followers_url":"https://api.github.com/users/kaduk/followers","following_url":"https://api.github.com/users/kaduk/following{/other_user}","gists_url":"https://api.github.com/users/kaduk/gists{/gist_id}","starred_url":"https://api.github.com/users/kaduk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kaduk/subscriptions","organizations_url":"https://api.github.com/users/kaduk/orgs","repos_url":"https://api.github.com/users/kaduk/repos","events_url":"https://api.github.com/users/kaduk/events{/privacy}","received_events_url":"https://api.github.com/users/kaduk/received_events","type":"User","site_admin":false},"created_at":"2018-07-04T15:59:24Z","updated_at":"2018-07-04T15:59:24Z","author_association":"CONTRIBUTOR","body":"It does seem that any sort of graceful transition would basically require separate configuration for the value that goes in the ticket and the value that is used when accepting a handshake.  In the absence of that, one would send ticket_lifetime of zero (or just not send tickets) for long enough that the 0-RTT-capable tickets would age out, and only then change the max early data size.  But losing all resumption around graceful change of max early data size is a really heavy hammer, so separate knobs seems like the way to go.  (As painful as it is to keep adding more and more state to the SSL/SSL_CTX structures.)"}}
{"actor":{"display_login":"kaduk"}}