{"action":"created","issue":{"url":"https://api.github.com/repos/openssl/openssl/issues/7433","repository_url":"https://api.github.com/repos/openssl/openssl","labels_url":"https://api.github.com/repos/openssl/openssl/issues/7433/labels{/name}","comments_url":"https://api.github.com/repos/openssl/openssl/issues/7433/comments","events_url":"https://api.github.com/repos/openssl/openssl/issues/7433/events","html_url":"https://github.com/openssl/openssl/issues/7433","id":371525669,"node_id":"MDU6SXNzdWUzNzE1MjU2Njk=","number":7433,"title":"TLS 1.3 fails to resume PSK sessions","user":{"login":"olszomal","id":27289366,"node_id":"MDQ6VXNlcjI3Mjg5MzY2","avatar_url":"https://avatars2.githubusercontent.com/u/27289366?v=4","gravatar_id":"","url":"https://api.github.com/users/olszomal","html_url":"https://github.com/olszomal","followers_url":"https://api.github.com/users/olszomal/followers","following_url":"https://api.github.com/users/olszomal/following{/other_user}","gists_url":"https://api.github.com/users/olszomal/gists{/gist_id}","starred_url":"https://api.github.com/users/olszomal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/olszomal/subscriptions","organizations_url":"https://api.github.com/users/olszomal/orgs","repos_url":"https://api.github.com/users/olszomal/repos","events_url":"https://api.github.com/users/olszomal/events{/privacy}","received_events_url":"https://api.github.com/users/olszomal/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-10-18T13:17:10Z","updated_at":"2018-10-18T14:15:12Z","closed_at":null,"author_association":"NONE","body":"OpenSSL 1.1.1 (or 1.1.2-dev) is unable to resume TLS 1.3 sessions created with a PSK cipher suite.\r\n\r\n### Steps to reproduce the bug\r\n\r\nI reproduced this problem using s_server and s_client diagnostic tools.\r\n\r\nI configured a PSK server:\r\n```\r\nopenssl s_server -accept 4433 -psk 1a2b3c4d -nocert\r\n```\r\n\r\n1st `openssl s_client` connection to create and save a session (works correctly):\r\n```\r\nopenssl s_client -connect 127.0.0.1:4433 -psk 1a2b3c4d -sess_out sesion\r\n```\r\n\r\n2nd `openssl s_client` connection to resume the saved session (fails):\r\n```\r\nopenssl s_client -connect 127.0.0.1:4433 -psk 1a2b3c4d -sess_in sesion\r\nCONNECTED(00000005)\r\n140476586415744:error:14094417:SSL routines:ssl3_read_bytes:sslv3 alert illegal parameter:ssl/record/rec_layer_s3.c:1528:SSL alert number 47\r\n```\r\n\r\nThe printed `openssl s_server` logs:\r\n```\r\nPSK warning: client identity not what we expected (got '<a number of garbage bytes>' expected 'Client_identity')\r\nERROR\r\n139982316717696:error:141FA0FD:SSL routines:tls_psk_do_binder:binder does not verify:ssl/statem/extensions.c:1604:\r\n```\r\n\r\n### My initial (and incomplete) analysis\r\n\r\nI diagnosed the garbage bytes to be generated by the `construct_stateless_ticket()` function on the server side, transferred via the `pkt` structure to the client, and stored in the `s->session->ext.tick` ticket on the client side.\r\n\r\nOn session resumption attempt only, the `tls_construct_ctos_psk()` function stores this value in the `pkt` structure on the client side. This value then becomes a parameter of the `psk_find_session_cb()` callback, producing the `PSK warning` message. Our `s_server` fails a bit further in the `tls_psk_do_binder()` function.\r\n\r\nI guess the issue is caused by a discrepancy between the server-side and client-side interpretation of the `pkt` structure.\r\n\r\nIt seems to be related to #7312"},"comment":{"url":"https://api.github.com/repos/openssl/openssl/issues/comments/431025763","html_url":"https://github.com/openssl/openssl/issues/7433#issuecomment-431025763","issue_url":"https://api.github.com/repos/openssl/openssl/issues/7433","id":431025763,"node_id":"MDEyOklzc3VlQ29tbWVudDQzMTAyNTc2Mw==","user":{"login":"mattcaswell","id":7422273,"node_id":"MDQ6VXNlcjc0MjIyNzM=","avatar_url":"https://avatars0.githubusercontent.com/u/7422273?v=4","gravatar_id":"","url":"https://api.github.com/users/mattcaswell","html_url":"https://github.com/mattcaswell","followers_url":"https://api.github.com/users/mattcaswell/followers","following_url":"https://api.github.com/users/mattcaswell/following{/other_user}","gists_url":"https://api.github.com/users/mattcaswell/gists{/gist_id}","starred_url":"https://api.github.com/users/mattcaswell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mattcaswell/subscriptions","organizations_url":"https://api.github.com/users/mattcaswell/orgs","repos_url":"https://api.github.com/users/mattcaswell/repos","events_url":"https://api.github.com/users/mattcaswell/events{/privacy}","received_events_url":"https://api.github.com/users/mattcaswell/received_events","type":"User","site_admin":false},"created_at":"2018-10-18T14:15:12Z","updated_at":"2018-10-18T14:15:12Z","author_association":"MEMBER","body":"> Also, comparing identity_len to the expected value (as implemented in #7434) won't work in real servers, which may accept several PSK identities. Some of those identities may have the same length as the session resumption.\r\n\r\nAny real callback needs to set the session to NULL and return 1 if it can't find a match for the identity. In s_server we only have one possible identity to match, so this way works just fine. The logic might look a little more complicated in a server with multiple valid identities but the principle is the same."}}
{"actor":{"display_login":"mattcaswell"}}