On 03/07/17 22:24, Neetish Pathak wrote: > Thanks Matt. This is quite useful. > Just to clarify my understanding based on your comments, OpenSSL code > and Draft for TLS 1.3/RFC for TLS1.2, please help me with following queries > > 1) So, when using external PSK (by creating the new session file), > client should mandatorily use SSL_CTX_set_psk_use_session_callback while > server should mandatorily use SSL_CTX_set_psk_find_session_casllback. > They both should use a common key (psk_key) to generate the new session > file and this common key is the one shared in advance to both client and > server. Yes, that is correct. If both client and server are OpenSSL then, optionally, they can just share a session file (which contains the key) if that is easier. > From the OpenSSL code, this key is used as char * type. So does > it mean that any pre-decided string can be used as a key and it does not > need any format etc. To me "string" implies NUL terminated printable string. Maybe that's not what you meant. Anyway in that sense "string" is not quite correct. The key is binary data which should be the same length as the hash used for the ciphersuite. > Both client and server create sessions based on the > key and connect based on the created session? > In one of the examples, *strspn*(psk_key, "abcdefABCDEF1234567890") is > used. So, I believe I can use any hex value string of my choice as psk_key. Like I said above - the key is *binary* data. It does not have to be a printable string. > 2) Also, from the man page , I found that PSK are used in TLS1.2 and > lower versions too and SSL_CTX_set_psk_server_callback > and SSL_CTX_set_psk_client_callback are used to set callback there. PSK > identity and Pre shared key is set there which can be used during the > connection. It is also written that these values are required when using > PSK cipher-suites. So, is my understanding correct that the role of PSK > in version <= TLS1.2 is only for using PSK ciphersuites > (e.g: ECDHE-PSK-AES256-CBC-SHA384) Correct. > and do not have anything to do with > session resumption and thereby do not provide any performance enhancement. They do not have anything to do with session resumption, so you don't see the reduced number of message flights that you get with a resumed handshake. However, PSK ciphersuites in <= TLS1.2 avoid the need to send (and therefore process/validate) Certificate messages which may have performance benefits. If the ciphersuite in use just uses "plain" PSK (i.e. no (EC)DHE or RSA) then a connection can be established without using public-key operations which may also have performance benefits (at the expense of forward secrecy). > Also, this PSK type ciphersuites are no longer valid for TLS 1.3. Correct. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
