I am hoping I am missing something fairly obvious but it would appear any interaction via command line (or if overridden by another application policy) with a site presenting TLSv1/SSLv3 initially is completely broken in F29
Since I upgraded to F29, any site I come across via SSL functionality (ex: github) that initially presents TLSv1/SSLv3, my commands will forcefully exit with a generic error message
curl https://github.com
curl: (35) error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback
openssl s_client -connect github.com:443
CONNECTED(00000004) 139888006719296:error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:ssl/statem/statem_lib.c:1929:
So I dug around a little bit and noticed it was because, in this example, github was first offering TLSv1/SSLv3
--- SSL handshake has read 3582 bytes and written 415 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256
However, because there is a StrongCryptoSettings set to disallow < TLS 1.2, it completely bombs out of the low level C functions with this obscure message. When I forcefully disable access to TLSv1 or 1.1 I can see that support for renegotiation is off but I can now communicate securely with github
openssl s_client -connect github.com:443 -no_tls1 -no_tls1_1 -no_tls1
{....} --- SSL handshake has read 3621 bytes and written 382 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_128_GCM_SHA256
My thought is that a better implementation would be to yes, continue to NOT support TLSv1/SSLv3 but do support renegotiating to > 1.2 rather than obscurely bombing out entirely...
So can anyone point me in the right direction to get this working again? I've reached out to github about the TLSv1/SSLv3 thing but I need a stopgap anyway. I cant seem to find a way to make git commands use something other than what openssl negotiates but if openssl libraries are bombing out before renegotiation then there seems to be very little I can do and I cant locate this policy that is referenced here https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
On 3/4/19 5:13 AM, Charles Kozler wrote:
curl https://github.com openssl s_client -connect github.com:443
CONNECTED(00000004) 139888006719296:error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:ssl/statem/statem_lib.c:1929:
I can't reproduce problems with those commands. Are you working in a site that uses TLS traffic inspection? If so, that would explain the problem. Traffic inspection services that haven't been updated to support TLS 1.3 will break for remote services that support 1.3, by design.
On 3/4/19 5:13 AM, Charles Kozler wrote:
I can't reproduce problems with those commands. Are you working in a site that uses TLS traffic inspection? If so, that would explain the problem. Traffic inspection services that haven't been updated to support TLS 1.3 will break for remote services that support 1.3, by design.
I am and the corporate firewall is out of my control
That being said, what exactly is the problem here then? As you can see from my outside test an initial v1 session is established and then a v1.3 is set after a secure renegotiation. Is it the filter that is not adhering or honoring the secure renegotiation and keeping me at TLSv1 and then F29 new rules are failing me out completely? In either case, the client should be able to receive the TLSv1 session but soft reject it by issuing a renegotiation as you can see in my external example - no?
Unless I am missing something fairly obvious, I still can't see why not supporting < 1.2 makes SSL routines hard-die..it should be more intuitive and/or easily configurable or documented better - no?
I am all for contributing but I just want to be sure there isnt something obvious that I somehow missed before I enter that rabbit hole
I figured the inspection was part of the problem, but it shouldnt be seen as the source of the problem
On 3/4/19 3:16 PM, Charles Kozler wrote:
That being said, what exactly is the problem here then?
That's complicated. https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/
See also section 2.2.3 of https://tools.ietf.org/id/draft-camwinget-tls-use-cases-03.html
We might be able to explain specifically what is broken with a packet capture file from tcpdump or wireshark, and we might not. Send one if you like. What I can say from experience is that TLS inspection middleware is often broken, and it will disrupt communications. It's not the client's fault.
On 3/4/19 3:16 PM, Charles Kozler wrote:
That's complicated. https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/
See also section 2.2.3 of https://tools.ietf.org/id/draft-camwinget-tls-use-cases-03.html
We might be able to explain specifically what is broken with a packet capture file from tcpdump or wireshark, and we might not. Send one if you like. What I can say from experience is that TLS inspection middleware is often broken, and it will disrupt communications. It's not the client's fault.
TLSv1.3 is not broken in my browser, in fact, it works fine and its only from command line tools.
I mean, I show exactly what the issue is...and while it would suggest it is two part, the fact is this didnt occur in < F29 and there is a link pointing out the changes to not support < TLS v1.3. While I am not disagreeing with the change in F29, there should still exist a workaround when there are millions of people who are behind a corporate filter or packet inspector. Just saying they're broken isn't a correct solution when a workaround should exist for this change in F29
It boils down to github offering TLSv1 session and the Palo Alto not honoring the secure renegotiation keeping the connection to TLSv1.1 of which the new policy changes in F29 break this - this is the two part problem but the breaking change was in the policy change in F29 - which is what brings me to this post to try to identify where in the system I change said policies
On 3/5/19 4:47 AM, Charles Kozler wrote:
I mean, I show exactly what the issue is...and while it would suggest it is two part, the fact is this didnt occur in < F29
I don't have an older release handy, and I don't know how its security policy is set. I will note that Google Chrome only enabled "full" support for TLS 1.3, with downgrade protection, in version 72 on Jan 30. It's barely one month old. The idea that full support wasn't turned on in F28 wouldn't surprise me at all.
and there is a link pointing out the changes to not support < TLS v1.3.
The link you found was a proposal. It has not been accepted yet: https://fedoraproject.org/wiki/Releases/29/ChangeSet
...also, the proposal was to disable TLS < 1.2, not 1.3.
It boils down to github offering TLSv1 session and the Palo Alto not honoring the secure renegotiation keeping the connection to TLSv1.1 of which the new policy changes in F29 break this - this is the two part problem but the breaking change was in the policy change in F29 - which is what brings me to this post to try to identify where in the system I change said policies
That's not now TLS works. Peers don't start with a low version and ratchet up, they start with the highest version they support and settle on the best possible. Your inspection device is downgrading the TLS protocol, and the endpoints can see that they support a higher version than they initially negotiated. TLS 1.3 prohibits that.
https://blog.gypsyengineer.com/en/security/how-does-tls-1-3-protect-against-...
As I mentioned previously, you need to disable TLS 1.3 to work around the problem. As far as I know, there's no system-wide way to do that. (See the man pages for crypto-policies and update-crypto-policies). You can set minimums system-wide, but not maximums. Once you disable support for 1.3, the client and server should negotiate tls 1.2 connections, which your inspection device presumably supports adequately.
on ipleak.net, i get fallback failed, do you get that too? i am chasing dns/ip leak after openvpn install. it IS a challenge.
On Mon, Mar 4, 2019 at 5:13 AM Charles Kozler ckozleriii@gmail.com wrote:
I am hoping I am missing something fairly obvious but it would appear any interaction via command line (or if overridden by another application policy) with a site presenting TLSv1/SSLv3 initially is completely broken in F29
Since I upgraded to F29, any site I come across via SSL functionality (ex: github) that initially presents TLSv1/SSLv3, my commands will forcefully exit with a generic error message
curl https://github.com
curl: (35) error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback
openssl s_client -connect github.com:443
CONNECTED(00000004) 139888006719296:error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:ssl/statem/statem_lib.c:1929:
So I dug around a little bit and noticed it was because, in this example, github was first offering TLSv1/SSLv3
SSL handshake has read 3582 bytes and written 415 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256
However, because there is a StrongCryptoSettings set to disallow < TLS 1.2, it completely bombs out of the low level C functions with this obscure message. When I forcefully disable access to TLSv1 or 1.1 I can see that support for renegotiation is off but I can now communicate securely with github
openssl s_client -connect github.com:443 -no_tls1 -no_tls1_1 -no_tls1
{....}
SSL handshake has read 3621 bytes and written 382 bytes Verification: OK
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_128_GCM_SHA256
My thought is that a better implementation would be to yes, continue to NOT support TLSv1/SSLv3 but do support renegotiating to > 1.2 rather than obscurely bombing out entirely...
So can anyone point me in the right direction to get this working again? I've reached out to github about the TLSv1/SSLv3 thing but I need a stopgap anyway. I cant seem to find a way to make git commands use something other than what openssl negotiates but if openssl libraries are bombing out before renegotiation then there seems to be very little I can do and I cant locate this policy that is referenced here https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Charles Kozler writes:
Since I upgraded to F29, any site I come across via SSL functionality (ex: github) that initially presents TLSv1/SSLv3, my commands will forcefully exit with a generic error message
curl https://github.com
curl: (35) error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback
Cannot reproduce. Works fine here.
On Mon, 4 Mar 2019 at 09:14, Charles Kozler ckozleriii@gmail.com wrote:
I am hoping I am missing something fairly obvious but it would appear any interaction via command line (or if overridden by another application policy) with a site presenting TLSv1/SSLv3 initially is completely broken in F29
Since I upgraded to F29, any site I come across via SSL functionality (ex: github) that initially presents TLSv1/SSLv3, my commands will forcefully exit with a generic error message
curl https://github.com
curl: (35) error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback
openssl s_client -connect github.com:443
CONNECTED(00000004) 139888006719296:error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:ssl/statem/statem_lib.c:1929:
So I dug around a little bit and noticed it was because, in this example, github was first offering TLSv1/SSLv3
[...]
My thought is that a better implementation would be to yes, continue to NOT support TLSv1/SSLv3 but do support renegotiating to > 1.2 rather than obscurely bombing out entirely...
So can anyone point me in the right direction to get this working again? I've reached out to github about the TLSv1/SSLv3 thing but I need a stopgap anyway. I cant seem to find a way to make git commands use something other than what openssl negotiates but if openssl libraries are bombing out before renegotiation then there seems to be very little I can do and I cant locate this policy that is referenced here https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Recent curl has --tlsv1.2 and --tlsv1.3 options. Do these allow you to connect to github?
There is a TLDNR discussion of policy management at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Mon, 4 Mar 2019 at 09:14, Charles Kozler <ckozleriii(a)gmail.com> wrote:
Recent curl has --tlsv1.2 and --tlsv1.3 options. Do these allow you to connect to github?
There is a TLDNR discussion of policy management at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Upon further inspection it seems I am only getting this issue with github host ending in .112. Requests to 113 seem to work fine
However, I am getting SSL interference via chrome with lists.fedoraproject.org as well -> https://i.imgur.com/wlU5FVE.png
So now I am even more confused but of course still not ruling out the ssl decryption for packet inspection...
[09:04:49]ckozler@myhost:~ > curl https://github.com --verbose * Rebuilt URL to: https://github.com/ * Trying 192.30.253.112... * TCP_NODELAY set * Connected to github.com (192.30.253.112) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (OUT), TLS alert, illegal parameter (559): * error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback * Closing connection 0 curl: (35) error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback
^ Error, so I try again
[09:04:51]ckozler@myhost:~ > curl https://github.com --verbose * Rebuilt URL to: https://github.com/ * Trying 192.30.253.113... * TCP_NODELAY set * Connected to github.com (192.30.253.113) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, [no content] (0): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, [no content] (0): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=Delaware; serialNumber=5157550; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com * start date: May 8 00:00:00 2018 GMT * expire date: Jun 3 12:00:00 2020 GMT * subjectAltName: host "github.com" matched cert's "github.com" * issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA * SSL certificate verify ok. * TLSv1.3 (OUT), TLS app data, [no content] (0):
GET / HTTP/1.1 Host: github.com User-Agent: curl/7.61.1 Accept: */*
And trying the ssl command
[09:07:30]ckozler@myhost:~ > !747 openssl s_client -connect github.com:443 CONNECTED(00000004) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA verify return:1 depth=0 businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 5157550, C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com verify return:1 --- Certificate chain 0 s:businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 5157550, C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIHQjCCBiqgAwIBAgIQCgYwQn9bvO1pVzllk7ZFHzANBgkqhkiG9w0BAQsFADB1 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE4MDUwODAwMDAwMFoXDTIwMDYwMzEy MDAwMFowgccxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF Ewc1MTU3NTUwMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG A1UEBxMNU2FuIEZyYW5jaXNjbzEVMBMGA1UEChMMR2l0SHViLCBJbmMuMRMwEQYD VQQDEwpnaXRodWIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xjyq8jyXDDrBTyitcnB90865tWBzpHSbindG/XqYQkzFMBlXmqkzC+FdTRBYyneZ w5Pz+XWQvL+74JW6LsWNc2EF0xCEqLOJuC9zjPAqbr7uroNLghGxYf13YdqbG5oj /4x+ogEG3dF/U5YIwVr658DKyESMV6eoYV9mDVfTuJastkqcwero+5ZAKfYVMLUE sMwFtoTDJFmVf6JlkOWwsxp1WcQ/MRQK1cyqOoUFUgYylgdh3yeCDPeF22Ax8AlQ xbcaI+GwfQL1FB7Jy+h+KjME9lE/UpgV6Qt2R1xNSmvFCBWu+NFX6epwFP/JRbkM fLz0beYFUvmMgLtwVpEPSwIDAQABo4IDeTCCA3UwHwYDVR0jBBgwFoAUPdNQpdag re7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFMnCU2FmnV+rJfQmzQ84mqhJ6kipMCUG A1UdEQQeMByCCmdpdGh1Yi5jb22CDnd3dy5naXRodWIuY29tMA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0 oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcy LmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2Vy dmVyLWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEF BQcBAQR8MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBS BggrBgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAA MIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgCkuQmQtBhYFIe7E6LMZ3AKPDWY BPkb37jjd80OyA3cEAAAAWNBYm0KAAAEAwBHMEUCIQDRZp38cTWsWH2GdBpe/uPT Wnsu/m4BEC2+dIcvSykZYgIgCP5gGv6yzaazxBK2NwGdmmyuEFNSg2pARbMJlUFg U5UAdgBWFAaaL9fC7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAWNBYm0tAAAE AwBHMEUCIQCi7omUvYLm0b2LobtEeRAYnlIo7n6JxbYdrtYdmPUWJQIgVgw1AZ51 vK9ENinBg22FPxb82TvNDO05T17hxXRC2IYAdgC72d+8H4pxtZOUI5eqkntHOFeV CqtS6BqQlmQ2jh7RhQAAAWNBYm3fAAAEAwBHMEUCIQChzdTKUU2N+XcqcK0OJYrN 8EYynloVxho4yPk6Dq3EPgIgdNH5u8rC3UcslQV4B9o0a0w204omDREGKTVuEpxG eOQwDQYJKoZIhvcNAQELBQADggEBAHAPWpanWOW/ip2oJ5grAH8mqQfaunuCVE+v ac+88lkDK/LVdFgl2B6kIHZiYClzKtfczG93hWvKbST4NRNHP9LiaQqdNC17e5vN HnXVUGw+yxyjMLGqkgepOnZ2Rb14kcTOGp4i5AuJuuaMwXmCo7jUwPwfLe1NUlVB Kqg6LK0Hcq4K0sZnxE8HFxiZ92WpV2AVWjRMEc/2z2shNoDvxvFUYyY1Oe67xINk myQKc+ygSBZzyLnXSFVWmHr3u5dcaaQGGAR42v6Ydr4iL38Hd4dOiBma+FXsXBIq WUjbST4VXmdaol7uzFMojA4zkxQDZAvF5XgJlAFadfySna/teik= -----END CERTIFICATE----- subject=businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 5157550, C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
--- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 3621 bytes and written 386 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_128_GCM_SHA256 Session-ID: 1D343EF008C16BCDF6BDA7AA5636893098AD63013754B70FE543CD02346B7199 Session-ID-ctx: Resumption PSK: FF94566A1ADC8640EEAAECA578A1AFFF4416DF8A9771E795FF6335F72EC7C642 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - a5 23 b4 47 52 ec f4 62-0d c6 f4 26 3d 21 b9 af .#.GR..b...&=!.. 0010 - 77 37 a8 a6 63 48 0f b6-56 50 98 5e 62 3f d1 25 w7..cH..VP.^b?.%
Start Time: 1551794858 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_128_GCM_SHA256 Session-ID: 8ABF9A302A2A03379168C62C4C54678E8C68C7D74A724EFE6017C2B6100D11E6 Session-ID-ctx: Resumption PSK: 7768F89C69C01E58381F3F63EC706ED78283D332DED9EA6E20246ACA9243520F PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - b2 09 02 b3 9a 80 23 b1-0b 65 6f 91 19 e6 a9 a7 ......#..eo..... 0010 - d8 3b 3f 68 b6 06 4b 76-07 a5 43 23 ae d8 24 19 .;?h..Kv..C#..$.
Start Time: 1551794858 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK q^[[A^C [09:07:42]ckozler@myhost:~ > openssl s_client -connect github.com:443 CONNECTED(00000004) 140189224101696:error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback:ssl/statem/statem_lib.c:1929: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 85 bytes and written 329 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- [09:07:43]ckozler@myhost:~ >
-
Charles Kozler -
George N. White III -
Gordon Messmer -
Jack Craig -
Sam Varshavchik