Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force enable SNI in socks request if SNI supported #757

Closed
1 task done
Puvipavan opened this issue Jun 22, 2022 · 3 comments · Fixed by #778
Closed
1 task done

Force enable SNI in socks request if SNI supported #757

Puvipavan opened this issue Jun 22, 2022 · 3 comments · Fixed by #778
Milestone

Comments

@Puvipavan
Copy link

Puvipavan commented Jun 22, 2022

Summary

It's 2022 and most of the servers are dropping support for the non SNI supported clients.
Following line disables SNI if the verify peer is disabled. It leads to connection error if the server does not support non SNI clients.

Line Numbers 127,128 & 129 must be removed in order to fix this issue.

Check done on following line: https://github.com/WordPress/Requests/blob/develop/src/Transport/Fsockopen.php#L127

I'd expect the following behaviour

Connection must be made without any error when SSL Verify is disabled

Instead this happened

Getting error:

stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:1408F10B:SSL routines:ssl3_get_record:wrong version number
stream_socket_client(): Failed to enable crypto stream_socket_client(): unable to connect to ssl://*********e.execute-api.us-east-1.amazonaws.com:443

Your environment

Environment Answer
Operating system and version (e.g. Ubuntu 20.04, Windows 10) Windows 10 and Ubuntu 18.0
PHP version 7.4.25
OpenSSL Version 1.1.1l

Tested against develop branch?

  • I have verified the issue still exists in the develop branch of Requests.
@schlessera
Copy link
Member

Checking here for the state of support for SNI: https://en.wikipedia.org/wiki/Server_Name_Indication

It looks like the initial code probably was built to support IE6.

From what I can tell when looking at the data, we should be safe by now to just expect clients & servers to support SNI.

@Puvipavan
Copy link
Author

Thanks for your insights on this. But don't know how IE6 relates with this issue.

Actually this is a bug. It didn't hurt before, because all of the servers were supporting non SNI supported clients when SNI was a new thing. However currently, most of the cloud solution providers don't support non SNI supported clients.
Ex: AWS API Gateway(Default Endpoint), Cloudflare(They support only if you add static IP - You must be an Enterprise Customer)

So,
Whenever PHP CURL is disabled(So it will fallback to socket connection) and SSL Verify Peer is set to false, This bug becomes headache.

And finally, you don't have to expect clients to support SNI(Still there are some old school systems). Just keep the OPENSSL_TLSEXT_SERVER_NAME check and if it supports SNI, don't disable SNI even if verify peer(verifyname) is set to false.

if (defined('OPENSSL_TLSEXT_SERVER_NAME') && OPENSSL_TLSEXT_SERVER_NAME) {
    $context_options['SNI_enabled'] = true;
}

This is how you can check whether the server supports non SNI Clients or not(This may help someone in the future):

Without SNI:
openssl s_client -connect google.com:443 -noservername - You need to add -noservername to not to supply SNI, otherwise it would automatically add the host name we specify in -connect if you are using OpenSSL >= 1.1.1*. If you are using older version then you can remove -noservername parameter

With SNI:
openssl s_client -connect google.com:443 -servername google.com - If you are testing with older version of OpenSSL <=1.1.1* then -servername is mandatory to supply SNI.


Sample Output with the Server which doesn't support non SNI Supported Clients(docs.aws.amazon.com):

Without SNI:

$ openssl s_client -connect docs.aws.amazon.com:443 -noservername
CONNECTED(00000003)
140021643126080:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 283 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)
---

With SNI:

$ openssl s_client -connect docs.aws.amazon.com:443 -servername docs.aws.amazon.com
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = docs.aws.amazon.com
verify return:1
---
Certificate chain
 0 s:CN = docs.aws.amazon.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF3jCCBMagAwIBAgIQAhUdHxmierIiLUYaI40O7DANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg
Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0yMTExMzAwMDAwMDBaFw0yMjExMDky
MzU5NTlaMB4xHDAaBgNVBAMTE2RvY3MuYXdzLmFtYXpvbi5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCulDz5GObRHFFaNhtyNTWWXvcmObBZ9Bu9
zczMOzF8gYToCLacvAbF4mOhVyredryTGXr3Hzv26Yes4DLPJbxpRwr7ynwj455C
ymPc0O8mVIdN9vnGy0gnXVeZW56pX+Q4OH2MlNF8W5wNHn3fqbsOrxnkgjVRWTE6
LdQ2MUkvqtZgYosID7LJ/2+/W3muHLN+E8UUyfxSzbuJ6J0Lmpzer0IAntcFbxg4
HHCWpQT2vSjajikhCZax8og2uwMnexO3dCEpgBNfg4uTQicco5y7g+b3+yOYF8Th
jy5pkLpkXs6VqO8I24TtMr4qC946mC8aEqJ9j3v7xIQIajg56YxlAgMBAAGjggLu
MIIC6jAfBgNVHSMEGDAWgBRZpGYGUqB7lZI8o5QHJ5Z0W/k90DAdBgNVHQ4EFgQU
Q77RDrADgRJlod/DjXZ83SfU574wHgYDVR0RBBcwFYITZG9jcy5hd3MuYW1hem9u
LmNvbTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9jcmwuc2NhMWIuYW1hem9udHJ1
c3QuY29tL3NjYTFiLTEuY3JsMBMGA1UdIAQMMAowCAYGZ4EMAQIBMHUGCCsGAQUF
BwEBBGkwZzAtBggrBgEFBQcwAYYhaHR0cDovL29jc3Auc2NhMWIuYW1hem9udHJ1
c3QuY29tMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LnNjYTFiLmFtYXpvbnRydXN0
LmNvbS9zY2ExYi5jcnQwDAYDVR0TAQH/BAIwADCCAX4GCisGAQQB1nkCBAIEggFu
BIIBagFoAHcAKXm+8J45OSHwVnOfY6V35b5XfZxgCvj5TV0mXCVdx4QAAAF9cQVn
9wAABAMASDBGAiEA9c9CEzceJaC0yNPNrrnUUpE9ofHXVz1obFjWqVt0orgCIQCI
Df6psf2vdG+kAXgAdmTRjpJanjLbn39L6QRSGfbRIwB1AFGjsPX9AXmcVm24N3iP
DKR6zBsny/eeiEKaDf7UiwXlAAABfXEFaGMAAAQDAEYwRAIgRT8kBEX5ge/5J+5L
H1O1SuzBsljs4DjTy5x4xL7wP1kCIEUKCk4nORy+mrlujy5BqRcsmqHQajO71oeA
kNJpUxazAHYAQcjKsd8iRkoQxqE6CUKHXk4xixsD6+tLx2jwkGKWBvYAAAF9cQVn
3wAABAMARzBFAiEA6SzmemjbbW5wAnw4ASsEYRqZ5kGepQOJOAYSh4HWl0sCIG6D
dzQSPXsRpo2NrFd5sjj+RPKtysLbvvJAIe27wHZmMA0GCSqGSIb3DQEBCwUAA4IB
AQB9Y0uEFKG3c1h2x2UAoksMs5bpocD1n6Dc6WEs4CQ1OOZMppYoLPl2kjNqCxVg
u8BiRVOJ+B4PTuz4aw+0kjRhXaQ8KaCRS92y2JiOy0vzeSXZx9HqGfN8vjQNTHH6
15MTE0kBnPrzL7eWMtKg3TH2TaYib+jgl1iRcYstUGerGxMriM8GDxEyWsLKK7Ma
tIQrKf1s8zy6P3VGSKSsXZZDnwRrX7mNFTQ0KvLtmxzlnI0QBCKe1LNEfP7z8fJQ
Bpi2j/XxGBWL5XT2l7oIS31B2abofeiVpTlACs2OZ26PoQ7yAO/nJIqjEUUfGT2K
jX+WBwhHV4ysMIduIVGFv1mm
-----END CERTIFICATE-----
subject=CN = docs.aws.amazon.com

issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

---
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 5485 bytes and written 375 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: 83630978F63160D7CFDB2F5431DE9E78BE45D5E31E5110059203CDC51AD72652
    Session-ID-ctx:
    Resumption PSK: 812113247EBE5DC6A4861BC3DAD3BDAE0DFCFAFA13BC3A8421651D2FC6990190
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 31 36 35 36 39 32 30 39-36 34 30 30 30 00 00 00   1656920964000...
    0010 - 71 d0 ea b9 db 8c 85 1f-8c fe 7e d2 28 fb 64 ef   q.........~.(.d.
    0020 - d4 b7 a8 64 93 f5 fc ce-28 80 74 61 9e 9e 46 2d   ...d....(.ta..F-
    0030 - 0d f5 ad c5 43 06 7c 0f-c3 25 47 f1 18 6e 8f 5f   ....C.|..%G..n._
    0040 - 8b ad 88 44 37 22 01 a8-9a 9c 0a d6 e7 98 99 30   ...D7".........0
    0050 - fb 1e 36 a3 a6 f9 f5 d1-b4 b6 c9 70 19 71 69 ea   ..6........p.qi.
    0060 - 10 16 d7 7c 49 ea 0e fd-ec                        ...|I....

    Start Time: 1656949238
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

@jrfnl
Copy link
Member

jrfnl commented Dec 15, 2022

PR #778, which will be included in the 2.1.0 release, should fix this.

@jrfnl jrfnl closed this as completed Dec 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants