dcooper16
commented
2 years ago Hello @srikr,
It's not clear to me what it is you are trying to accomplish, but it doesn't seem to be in line with the way that testssl.sh works. In most cases, testssl.sh sends a CientHello and then just wants a small amount of information about the server's response (e.g., what protocol version or cipher suite did the server choose). For this reason, testssl.sh never completes the TLS handshake and does not derive session keys. So, sending application traffic would not be a possibility. As you noted, in the few places where testssl.sh needs to send application traffic, it uses OpenSSL.
In the case of TLS 1.3, a lot of the server's response is encrypted. With TLS 1.2 and earlier, tls_sockets() can easily extract the extensions and the certificates that the server sends, but this is all encrypted in TLS 1.3. So, I wrote a lot of code to derive the traffic keys for a TLS 1.3 handshake so that tls_sockets() could decrypt the extensions and certificates. (Extending this to work with TLS 1.2 or earlier would be too much work, since there are so many different options involved).
Once I had written the code for TLS 1.3 to derive the keys and decrypt the extensions and certificates, I went one step further and wrote code to complete the handshake and then send application data, but this code isn't yet being used. Also, since tls_sockets() is relatively slow, it does the least work possible. The application traffic keys are only derived if data needs to be decrypted, and the handshake is only completed if the call to tls_sockets() specifically requests that. At the moment, with one exception, no call to tls_sockets() asks for the handshake to be completed, and my guess would be that most do not call for the session keys to be derived. So, sending application data with each call to tls_sockets() would be a major change to the way that the code currently works.
I also don't understand the reason you want to send this data every time. If the purpose of a call to tls_sockets() is to find out if a particular cipher suite is supported or to obtain the server's certificate, the information needed is obtained before the handshake is complete, so what benefit is there in completing the handshake and then sending application data?
In any case, the best place to look is the only place at the moment in testssl.sh that attempts to send application data over TLS, service_detection(). This is a place where application does need to be send. Ideally OpenSSL is used, but if the server only supports TLS 1.3 and OpenSSL does not support TLS 1.3, then it tries using tls_sockets(). It might not work (the code does not work reliably at the moment), but it's better than not even trying. A short snippet of the code is as follows:
tls_sockets "04" "$TLS13_CIPHER" "all+" "" "" false
if [[ $? -eq 0 ]]; then
plaintext="$(tm_out "$GET_REQ11" | hexdump -v -e '16/1 "%02X"')"
plaintext="${plaintext%%[!0-9A-F]*}"
send_app_data "$plaintext"
if [[ $? -eq 0 ]]; then
receive_app_data true
[[ $? -eq 0 ]] || > "$TMPFILE"
else
> "$TMPFILE"
fi
send_close_notify "$DETECTED_TLS_VERSION"
fiIf receive_app_data() is successful, the received data will be in $TMPFILE.
Note that in order for this to work, the server must support TLS 1.3, and in the call to tls_sockets() the third parameter must be all+ and the sixth parameter must be false. This call to tls_sockets() in service_detection() is the only one in testssl.sh that specifies these parameters in this way.
srikr
drwetter
Which version are you referring to 3.0.x or 3.1dev? (please check also how old your version is compare to the ones here) Hi, I am using 3.1dev testssl.sh version where in which I am trying to Test TLS Fingerprint for BOT. I am impressed with the SSL Testing options this tool provides only thing is on top of all the SSL Negative/Positive Testing I wanted HTTP Application Encrypted Traffic to be sent using the same Sockets. Below are something I was trying to do to achieve the same but failed: a) Initially inside tls_socket() function I tried to call socksend with HTTP App Data, it did send but the problem is it is sending in Plain Text resulting in Failure b) Then I tried to traverse the code and see to calculate session keys based on the Server Hello Packet what my Server Exchanges it is not able to do following due to no handshake_secret and msg_transcript getting derived:
master_secret="$(derive-master-secret "$cipher" "$handshake_secret")" master_traffic_keys="$(derive-application-traffic-keys "$cipher" "$master_secret" "$msg_transcript" server)" APP_TRAF_KEY_INFO="$tls_version $cipher $master_traffic_keys 0 " master_traffic_keys="$(derive-application-traffic-keys "$cipher" "$master_secret" "$msg_transcript" client)" APP_TRAF_KEY_INFO+="$master_traffic_keys 0"c) I also tried to use send_app_data() which said(# Send application data over a TLS 1.3 channel that has already been created.) it can be only use with TLS1.3 and not TLS1.2 so I dropped. Even it is only for TLS1.3 I tried to use that but it needs following parameter as inputread -r tls_version cipher server_key server_iv server_seq client_key client_iv client_seq <<< "$APP_TRAF_KEY_INFO"which I am not able to derive result in failure. I am not sure how to proceed after this now, It would be great if I can get some help in achieving the same. I am also attaching TCPDump [vs_virtualservice-abd75ca8-f7cb-4c24-bd19-a937d920b8d5.1651833023.zip] of the grease ciphersuite tests(TLS Stream 18 in wireshark or client hello packet number 348) for your reference (Note: There are few places, tool sends HTTP Encrypted Traffic but not using same TLS sockets though rather uses separate openssl commands which uses different TLS Params but I wanted Encrypted Application Traffic to be sent in all the places through the same sockets and same TLS Params during running the test like grease cipher, grease extension and other SSL Vulnerabilities etc)