Ssl error syscall in connection - Исправление ошибок и поиск оптимальных решений проблем

SSL_ERROR_SYSCALL typically occurs when the server side is using an SSL certificate to authenticate. This article covers how to fix SSL_ERROR_SYSCALL error in 5 ways.

SSL_ERROR_SYSCALL Error

$ git clone https://github.com/xxx/xxx.git
fatal: unable to access ‘https://github.com/xxx/xxx.git/’: LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443

Understanding SSL_ERROR_SYSCALL Error

This error typically occurs when the TCP three-way handshake between client and server completes but then a TCP reset packet (often written as “RST”) is received by the client, terminating the connection during the SSL phase.

This error is not produced when a client receives a RST packet during the three-way handshake, or after completion of the SSL/TLS negotiation (SSL phase).

Restart the computer

As we all know, restarting solves 90% of problems, and sometimes restarting the computer can directly solve the problem.

Modify Git network configuration

We can directly modify the global Git configuration file and delete the relevant configuration of HTTP / HTTPS in the file.

$ vim ~/.gitconfig

It can also be modified using the command:

$ git config –global –unset http.proxy
$ git config –global –unset https.proxy

Check SSL Certificate with OpenSSL

Change HTTP/HTTPS encryption library

Since the problem is that the LibreSSL library reports an error, we can modify Git to use the OpenSSL library for HTTPS communication.

$ git config –global http.sslBackend “openssl”

Use HTTPS proxy for git connection

When using HTTPS to connect to GitHub for push/pull, we need to change the local git configuration and use a proxy to initiate a request to GitHub.

Execute the following command: $ git config –global -e

This will bring us into git’s configuration file editing interface (which will open with the default editor specified by git). Add the following to this file:

[http]
proxy = socks5://127.0.0.1:7891
[https]
proxy = socks5://127.0.0.1:7891

“7891” is the designated entry and exit port of our proxy software, please modify it according to the actual situation.

Use SSH for git connection

It is well known that HTTPS or SSH can be used to clone the GitHub repository, but SSH does not have the network connection problem of HTTPS, so the connection method of push/pull can be changed from HTTPS to SSH.

Requirements: we need to generate an SSH public/private key pair in advance and add the public key to our GitHub account. See Connecting to GitHub with SSH for details on this part .

Enter the corresponding directory of the warehouse and execute the following command: $ git remote set-url origin git@github.com:xxx/xxx.git

After the change is complete, we can use the following command to view the current origin address:

$ git remote -v

Understanding X509 Certificate with Openssl Command

Источник

Openssl-11.1.c have TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 support.
But, still have interoperability problems with TomCat (homologacao.sefaz.mt.gov.br).
Attached the log build with -ssl-trace:
The the interesting part is the server dot not sent this record:

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 36
    CertificateRequest, Length=32
      certificate_types (len=3)
        rsa_sign (1)
        dss_sign (2)
        ecdsa_sign (64)
      signature_algorithms (len=24)
        rsa_pkcs1_sha256 (0x0401)
        dsa_sha256 (0x0402)
        ecdsa_secp256r1_sha256 (0x0403)
        rsa_pkcs1_sha384 (0x0501)
        dsa_sha384 (0x0502)
        ecdsa_secp384r1_sha384 (0x0503)
        rsa_pkcs1_sha512 (0x0601)
        dsa_sha512 (0x0602)
        ecdsa_secp521r1_sha512 (0x0603)
        rsa_pkcs1_sha1 (0x0201)
        dsa_sha1 (0x0202)
        ecdsa_sha1 (0x0203)
      certificate_authorities (len=0)

He sents this record:
Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 4
    ServerHelloDone, Length=0

I belive thats is cause the error.
Now the question is why server is not ordering the CertificateRequest record?

-----------------------------------------------------------------------------------
CONNECTED(00000798)
Sent Record
Header:
  Version = TLS 1.0 (0x301)
  Content Type = Handshake (22)
  Length = 225
    ClientHello, Length=221
      client_version=0x303 (TLS 1.2)
      Random:
        gmt_unix_time=0x4CD41B00
        random_bytes (len=28): 8C19FCA4AF5ABC5A3E12BC1F21E4E63B9103FBE1AC1CDF28E850D9DA
      session_id (len=0): 
      cipher_suites (len=56)
        {0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        {0xC0, 0x30} TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        {0x00, 0x9F} TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
        {0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        {0xCC, 0xA8} TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        {0xCC, 0xAA} TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
        {0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        {0xC0, 0x2F} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        {0x00, 0x9E} TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
        {0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
        {0xC0, 0x28} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
        {0x00, 0x6B} TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
        {0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
        {0xC0, 0x27} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        {0x00, 0x67} TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
        {0xC0, 0x0A} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
        {0xC0, 0x14} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        {0x00, 0x39} TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        {0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
        {0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        {0x00, 0x33} TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        {0x00, 0x9D} TLS_RSA_WITH_AES_256_GCM_SHA384
        {0x00, 0x9C} TLS_RSA_WITH_AES_128_GCM_SHA256
        {0x00, 0x3D} TLS_RSA_WITH_AES_256_CBC_SHA256
        {0x00, 0x3C} TLS_RSA_WITH_AES_128_CBC_SHA256
        {0x00, 0x35} TLS_RSA_WITH_AES_256_CBC_SHA
        {0x00, 0x2F} TLS_RSA_WITH_AES_128_CBC_SHA
        {0x00, 0xFF} TLS_EMPTY_RENEGOTIATION_INFO_SCSV
      compression_methods (len=1)
        No Compression (0x00)
      extensions, length = 124
        extension_type=server_name(0), length=32
          0000 - 00 1e 00 00 1b 68 6f 6d-6f 6c 6f 67 61 63 61   .....homologaca
          000f - 6f 2e 73 65 66 61 7a 2e-6d 74 2e 67 6f 76 2e   o.sefaz.mt.gov.
          001e - 62 72                                          br
        extension_type=ec_point_formats(11), length=4
          uncompressed (0)
          ansiX962_compressed_prime (1)
          ansiX962_compressed_char2 (2)
        extension_type=supported_groups(10), length=12
          ecdh_x25519 (29)
          secp256r1 (P-256) (23)
          ecdh_x448 (30)
          secp521r1 (P-521) (25)
          secp384r1 (P-384) (24)
        extension_type=session_ticket(35), length=0
        extension_type=encrypt_then_mac(22), length=0
        extension_type=extended_master_secret(23), length=0
        extension_type=signature_algorithms(13), length=48
          ecdsa_secp256r1_sha256 (0x0403)
          ecdsa_secp384r1_sha384 (0x0503)
          ecdsa_secp521r1_sha512 (0x0603)
          ed25519 (0x0807)
          ed448 (0x0808)
          rsa_pss_pss_sha256 (0x0809)
          rsa_pss_pss_sha384 (0x080a)
          rsa_pss_pss_sha512 (0x080b)
          rsa_pss_rsae_sha256 (0x0804)
          rsa_pss_rsae_sha384 (0x0805)
          rsa_pss_rsae_sha512 (0x0806)
          rsa_pkcs1_sha256 (0x0401)
          rsa_pkcs1_sha384 (0x0501)
          rsa_pkcs1_sha512 (0x0601)
          ecdsa_sha224 (0x0303)
          ecdsa_sha1 (0x0203)
          rsa_pkcs1_sha224 (0x0301)
          rsa_pkcs1_sha1 (0x0201)
          dsa_sha224 (0x0302)
          dsa_sha1 (0x0202)
          dsa_sha256 (0x0402)
          dsa_sha384 (0x0502)
          dsa_sha512 (0x0602)

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 95
    ServerHello, Length=91
      server_version=0x303 (TLS 1.2)
      Random:
        gmt_unix_time=0x5D2695FE
        random_bytes (len=28): 11250502DB25FAE8E20B480E4D5EAD49E35681BD23390EF7B872805A
      session_id (len=32): D208D422264D4807BBD098018C95F08F0A713226B30B5303FE9717665E25409F
      cipher_suite {0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
      compression_method: No Compression (0x00)
      extensions, length = 19
        extension_type=renegotiate(65281), length=1
            <EMPTY>
        extension_type=server_name(0), length=0
        extension_type=ec_point_formats(11), length=2
          uncompressed (0)
        extension_type=extended_master_secret(23), length=0

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 2816
    Certificate, Length=2812
      certificate_list, length=2809
        ASN.1Cert, length=1629
------details-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:85:45:46:11:10:a6:1e:54:31:48:31:62:52:64:7e:5b:72
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Jul 31 13:04:24 2019 GMT
            Not After : Oct 29 13:04:24 2019 GMT
        Subject: CN = *.sefaz.mt.gov.br
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:d9:95:a3:f5:48:79:04:b7:0a:d3:a2:47:0b:ab:
                    ac:70:f7:3d:b5:d0:00:33:99:53:21:5c:20:c1:eb:
                    3e:d5:6b:48:ec:6a:2a:dd:d5:3a:4b:52:d5:e3:64:
                    8f:c1:50:63:2f:64:78:7d:77:d6:1d:06:56:80:93:
                    1a:6b:cd:e7:52:5a:35:e1:3b:86:d4:12:82:1e:f0:
                    66:8a:bd:26:e3:87:0a:71:21:b2:64:55:15:f3:19:
                    1c:03:a6:53:bb:c3:cd:a1:6d:73:09:4a:58:57:6c:
                    f7:92:b2:8d:c6:a1:05:42:17:08:45:2b:2f:80:8e:
                    78:9d:e3:2f:76:45:72:24:50:2a:83:f0:5b:64:9b:
                    4e:ab:ef:60:d8:d2:9b:81:f9:7f:ef:7d:a8:49:0c:
                    74:5d:a4:6f:bf:23:57:5a:02:1f:1c:21:8c:52:bb:
                    e8:84:e4:86:38:93:a3:f1:14:c8:0f:ba:0d:b8:6e:
                    48:49:ec:8b:de:3a:f6:11:fd:b3:e3:4f:87:ba:ac:
                    48:d4:c0:b5:25:f5:ca:e1:99:94:8f:a3:23:ba:6a:
                    a3:f5:0d:6c:ee:32:d5:bf:42:f8:6f:62:12:80:e7:
                    99:1c:3d:23:7c:18:a3:ab:23:2b:94:db:c0:89:fb:
                    65:e8:fc:e5:9a:92:4c:37:9c:ee:99:2f:e1:4e:d2:
                    2d:b0:bc:62:04:41:0b:f9:6b:2f:54:10:e9:c9:cf:
                    54:cc:15:69:8f:15:28:12:d7:62:29:16:b6:87:cd:
                    a4:48:cf:2c:d9:3b:71:2c:9d:9a:7d:40:c8:5d:d5:
                    99:3a:c6:31:5f:01:bb:ac:e0:a9:b7:44:23:49:7e:
                    2f:27:30:18:21:8e:f8:44:73:b1:6a:58:e8:88:55:
                    3e:6e:08:47:5d:23:0d:65:45:d8:38:5c:88:31:2a:
                    ca:0a:1e:f7:b2:39:06:08:6e:a2:39:4b:90:cb:6b:
                    ce:5d:21:ff:e7:da:43:da:cc:f8:0c:c8:1d:82:6b:
                    b2:36:76:e2:a1:72:20:1d:57:8f:41:f2:88:0d:9d:
                    92:79:a6:2f:0c:77:33:aa:30:9e:58:39:15:25:ba:
                    65:eb:e9:40:04:6d:29:24:ad:18:40:8d:0a:88:ca:
                    78:92:fd:85:a0:76:3c:f5:3d:1a:d4:24:77:6f:fa:
                    71:03:6c:04:bc:86:7e:96:53:bf:3d:ad:0b:e8:b6:
                    37:3d:9d:d2:99:77:24:84:01:b7:e6:97:08:d7:34:
                    29:2e:85:3b:47:a4:fc:d8:83:29:ce:05:4d:8a:db:
                    17:30:ff:90:2d:eb:08:e0:2a:79:7d:d6:37:1a:08:
                    a7:5f:0b:94:74:77:3a:dc:9d:91:d6:b6:b5:ae:c5:
                    9c:15:15
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                19:42:7E:8C:A9:A8:8E:8E:EB:D1:7A:83:51:E2:9D:62:D4:D2:2D:C8
            X509v3 Authority Key Identifier: 
                keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

            Authority Information Access: 
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

            X509v3 Subject Alternative Name: 
                DNS:*.sefaz.mt.gov.br
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 74:7E:DA:83:31:AD:33:10:91:21:9C:CE:25:4F:42:70:
                                C2:BF:FD:5E:42:20:08:C6:37:35:79:E6:10:7B:CC:56
                    Timestamp : Jul 31 14:04:24.522 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:0F:0F:9A:74:E9:B2:DC:BA:F0:BB:D4:66:
                                43:3B:7A:99:4E:99:9B:52:8A:12:71:BA:65:37:D8:EE:
                                1C:93:71:B9:02:20:41:30:E0:D6:14:E6:94:83:68:69:
                                0B:5B:25:C0:75:71:27:84:16:0C:61:F5:6C:17:F4:1A:
                                34:C0:F7:C0:18:00
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
                                6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
                    Timestamp : Jul 31 14:04:24.569 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:52:52:D5:86:CB:72:7F:FA:D7:60:9C:08:
                                F1:77:EC:AB:A1:09:DE:EB:30:B9:53:24:AF:05:D4:BC:
                                B7:C5:7F:68:02:21:00:EF:6C:86:4C:A7:1B:FB:7B:7E:
                                BD:50:EF:6C:C6:35:9D:40:1E:C6:AF:6B:AA:37:CA:2F:
                                25:F4:49:41:A3:4F:71
    Signature Algorithm: sha256WithRSAEncryption
         5a:c0:33:7d:c0:37:53:ce:14:e7:b8:f1:6c:65:0c:a8:49:d2:
         f0:2a:ca:d4:f0:a4:5e:27:88:30:30:ce:4f:8e:df:fc:f8:67:
         86:be:da:45:c8:48:e5:5a:eb:cc:eb:66:08:09:d8:2c:52:a1:
         28:f7:1d:55:99:94:8e:0a:ce:a8:62:75:2b:8b:ba:11:8c:d5:
         8d:fb:34:b5:cf:3e:e1:40:33:3e:ae:50:30:f9:d4:60:d0:07:
         7f:76:ef:b2:85:2a:58:57:37:35:23:1f:aa:55:73:f2:a5:40:
         9f:74:d1:e0:6e:66:fe:a4:4d:3a:47:4b:33:48:a1:f1:49:c1:
         af:61:ab:c2:74:e4:1c:63:f5:df:e2:0d:a9:58:bf:c3:c2:0a:
         0b:cf:c6:23:be:82:c2:60:8c:32:81:eb:c7:fa:fa:71:93:4e:
         3f:d6:ea:51:ce:8b:5e:ca:4c:8b:f0:48:28:9f:a0:52:f2:d1:
         34:ed:aa:3e:ae:22:0a:e9:57:0a:4b:47:49:b4:d0:52:44:32:
         1d:5e:30:ec:44:d0:a6:fc:0e:fa:4a:31:b0:bd:c2:aa:d5:38:
         e3:1c:7b:88:d8:e8:8b:4d:e1:9a:b8:1f:b9:af:e1:be:47:42:
         fc:91:49:ef:a2:6e:c5:78:cd:31:74:30:53:b2:ce:7e:59:ad:
         bb:ec:9a:de
-----BEGIN CERTIFICATE-----
MIIGWTCCBUGgAwIBAgISA4VFRhEQph5UMUgxYlJkfltyMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA3MzExMzA0MjRaFw0x
OTEwMjkxMzA0MjRaMBwxGjAYBgNVBAMMESouc2VmYXoubXQuZ292LmJyMIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2ZWj9Uh5BLcK06JHC6uscPc9tdAA
M5lTIVwgwes+1WtI7Goq3dU6S1LV42SPwVBjL2R4fXfWHQZWgJMaa83nUlo14TuG
1BKCHvBmir0m44cKcSGyZFUV8xkcA6ZTu8PNoW1zCUpYV2z3krKNxqEFQhcIRSsv
gI54neMvdkVyJFAqg/BbZJtOq+9g2NKbgfl/732oSQx0XaRvvyNXWgIfHCGMUrvo
hOSGOJOj8RTID7oNuG5ISeyL3jr2Ef2z40+HuqxI1MC1JfXK4ZmUj6Mjumqj9Q1s
7jLVv0L4b2ISgOeZHD0jfBijqyMrlNvAiftl6PzlmpJMN5zumS/hTtItsLxiBEEL
+WsvVBDpyc9UzBVpjxUoEtdiKRa2h82kSM8s2TtxLJ2afUDIXdWZOsYxXwG7rOCp
t0QjSX4vJzAYIY74RHOxaljoiFU+bghHXSMNZUXYOFyIMSrKCh73sjkGCG6iOUuQ
y2vOXSH/59pD2sz4DMgdgmuyNnbioXIgHVePQfKIDZ2SeaYvDHczqjCeWDkVJbpl
6+lABG0pJK0YQI0KiMp4kv2FoHY89T0a1CR3b/pxA2wEvIZ+llO/Pa0L6LY3PZ3S
mXckhAG35pcI1zQpLoU7R6T82IMpzgVNitsXMP+QLesI4Cp5fdY3GginXwuUdHc6
3J2R1ra1rsWcFRUCAwEAAaOCAmUwggJhMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE
FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU
GUJ+jKmojo7r0XqDUeKdYtTSLcgwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl
7/Oo7KEwbwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5p
bnQteDMubGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5p
bnQteDMubGV0c2VuY3J5cHQub3JnLzAcBgNVHREEFTATghEqLnNlZmF6Lm10Lmdv
di5icjBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsG
AQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQMGCisGAQQB1nkC
BAIEgfQEgfEA7wB1AHR+2oMxrTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAAB
bEhYpEoAAAQDAEYwRAIgDw+adOmy3Lrwu9RmQzt6mU6Zm1KKEnG6ZTfY7hyTcbkC
IEEw4NYU5pSDaGkLWyXAdXEnhBYMYfVsF/QaNMD3wBgAAHYAKTxRllTIOWW6qlD8
WAfUt2+/WHopctykwwz05UVH9HgAAAFsSFikeQAABAMARzBFAiBSUtWGy3J/+tdg
nAjxd+yroQne6zC5UySvBdS8t8V/aAIhAO9shkynG/t7fr1Q72zGNZ1AHsava6o3
yi8l9ElBo09xMA0GCSqGSIb3DQEBCwUAA4IBAQBawDN9wDdTzhTnuPFsZQyoSdLw
KsrU8KReJ4gwMM5Pjt/8+GeGvtpFyEjlWuvM62YICdgsUqEo9x1VmZSOCs6oYnUr
i7oRjNWN+zS1zz7hQDM+rlAw+dRg0Ad/du+yhSpYVzc1Ix+qVXPypUCfdNHgbmb+
pE06R0szSKHxScGvYavCdOQcY/Xf4g2pWL/DwgoLz8YjvoLCYIwygevH+vpxk04/
1upRzoteykyL8Egon6BS8tE07ao+riIK6VcKS0dJtNBSRDIdXjDsRNCm/A76SjGw
vcKq1TjjHHuI2OiLTeGauB+5r+G+R0L8kUnvom7FeM0xdDBTss5+Wa277Jre
-----END CERTIFICATE-----
------------------
        extensions, length = 4
extensions, extype = 38448, extlen = 33284
          0000 - 96 30 82 04                                    .0..
Message length parse error!

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 589
    ServerKeyExchange, Length=585
      KeyExchangeAlgorithm=ECDHE
        named_curve: secp256r1 (P-256) (23)
        point (len=65): 0423B2D4441B9AE65E5B3F885C80E63AC87F3F162C168CC0B99DC3ECDA184838A4A6CAC65CD3A10185101590EE4328B09C6B8BB5537DFA077C7926DFF9F673C12A
      Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
      Signature (len=512): 24B6E1D604A150B1B977854AA5C0883DCA5D8BA51DAC648C7789FA67FB69F23064F71B111315EAC61CCCB41ECD8DF4670AD45C309CB74F01191246A42C0228E42E974950F7630889430F9B6E45AC787BB20168712B9343C6EA573944C4E5852C83C6C24E03673F5467242FB654F1D9D2FE33413E1AB50D7E5EB93C764DD7CC81E2026C5BCCE983F192969CCDFDDDEC7EDE48702FEF54A889FE48132FF0F339BFDC84304F0A19C6669C59EAAE45351B02833B24DAD75E3BBAAB6471EAAD1D13B21F59CAC74DE097F6037EE6646781F79EEFC44EA742385AE6C9CA3BF8ACEBFB4B11ED5007E032616C5DFB3330F6EB3F770947804D29782846BDD4B53F0B8EB8EEB2F6D5E42A1B240E63733F79004CE64B72DBD867ACBEEC51421B210CB667D2F71D75A96679380DE4005F027BBD3C8C5BA21A0C6DF4F504A40DA9B6B41FB74FCE5A1F2D34466A01BBAF72696BB13AE9863076B4776A08EDD4F415C827EC1B0D4DFFBB0E5A2DB5C587440A0F3554300B041D6B1B24AFE07D9F4F5E2D8D6DC7E6370F50B16D6E0093C5018484BB49B7F65B4CED9E07006F390AC1719B00C027B0154FBAF799B761CE43CA4C9C92E8C348CD1403F005A9B2DE284950C76CFFE2FFEDDC763DB74AE279E77AC80E13157401A6475012C4C4BA252CD126966B5F084A50045DBC47D741BF0D942FDA391DE39E0770F0FED771FA5A191C92138E9CBE36A8

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 4
    ServerHelloDone, Length=0

Sent Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 70
    ClientKeyExchange, Length=66
      KeyExchangeAlgorithm=ECDHE
        ecdh_Yc (len=65): 04A2C8F7CB0383A48DEE27AF79D9D210D4A346FAA44784604A11D003CC6488C547C693CEF141AED0535E0ECF67B3974CCCA85D3251C7E64B5FF1CBD4F68F963BAD

Sent Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = ChangeCipherSpec (20)
  Length = 1
    change_cipher_spec (1)

Sent Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 64
    Finished, Length=12
      verify_data (len=12): 063BF14FCCDDC30F56E193C3

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = ChangeCipherSpec (20)
  Length = 1
Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Handshake (22)
  Length = 64
    Finished, Length=12
      verify_data (len=12): CEE155B9EEBB61BE4BE37AD6

---
Certificate chain
 0 s:CN = *.sefaz.mt.gov.br
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGWTCCBUGgAwIBAgISA4VFRhEQph5UMUgxYlJkfltyMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA3MzExMzA0MjRaFw0x
OTEwMjkxMzA0MjRaMBwxGjAYBgNVBAMMESouc2VmYXoubXQuZ292LmJyMIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2ZWj9Uh5BLcK06JHC6uscPc9tdAA
M5lTIVwgwes+1WtI7Goq3dU6S1LV42SPwVBjL2R4fXfWHQZWgJMaa83nUlo14TuG
1BKCHvBmir0m44cKcSGyZFUV8xkcA6ZTu8PNoW1zCUpYV2z3krKNxqEFQhcIRSsv
gI54neMvdkVyJFAqg/BbZJtOq+9g2NKbgfl/732oSQx0XaRvvyNXWgIfHCGMUrvo
hOSGOJOj8RTID7oNuG5ISeyL3jr2Ef2z40+HuqxI1MC1JfXK4ZmUj6Mjumqj9Q1s
7jLVv0L4b2ISgOeZHD0jfBijqyMrlNvAiftl6PzlmpJMN5zumS/hTtItsLxiBEEL
+WsvVBDpyc9UzBVpjxUoEtdiKRa2h82kSM8s2TtxLJ2afUDIXdWZOsYxXwG7rOCp
t0QjSX4vJzAYIY74RHOxaljoiFU+bghHXSMNZUXYOFyIMSrKCh73sjkGCG6iOUuQ
y2vOXSH/59pD2sz4DMgdgmuyNnbioXIgHVePQfKIDZ2SeaYvDHczqjCeWDkVJbpl
6+lABG0pJK0YQI0KiMp4kv2FoHY89T0a1CR3b/pxA2wEvIZ+llO/Pa0L6LY3PZ3S
mXckhAG35pcI1zQpLoU7R6T82IMpzgVNitsXMP+QLesI4Cp5fdY3GginXwuUdHc6
3J2R1ra1rsWcFRUCAwEAAaOCAmUwggJhMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE
FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU
GUJ+jKmojo7r0XqDUeKdYtTSLcgwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl
7/Oo7KEwbwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5p
bnQteDMubGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5p
bnQteDMubGV0c2VuY3J5cHQub3JnLzAcBgNVHREEFTATghEqLnNlZmF6Lm10Lmdv
di5icjBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsG
AQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQMGCisGAQQB1nkC
BAIEgfQEgfEA7wB1AHR+2oMxrTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAAB
bEhYpEoAAAQDAEYwRAIgDw+adOmy3Lrwu9RmQzt6mU6Zm1KKEnG6ZTfY7hyTcbkC
IEEw4NYU5pSDaGkLWyXAdXEnhBYMYfVsF/QaNMD3wBgAAHYAKTxRllTIOWW6qlD8
WAfUt2+/WHopctykwwz05UVH9HgAAAFsSFikeQAABAMARzBFAiBSUtWGy3J/+tdg
nAjxd+yroQne6zC5UySvBdS8t8V/aAIhAO9shkynG/t7fr1Q72zGNZ1AHsava6o3
yi8l9ElBo09xMA0GCSqGSIb3DQEBCwUAA4IBAQBawDN9wDdTzhTnuPFsZQyoSdLw
KsrU8KReJ4gwMM5Pjt/8+GeGvtpFyEjlWuvM62YICdgsUqEo9x1VmZSOCs6oYnUr
i7oRjNWN+zS1zz7hQDM+rlAw+dRg0Ad/du+yhSpYVzc1Ix+qVXPypUCfdNHgbmb+
pE06R0szSKHxScGvYavCdOQcY/Xf4g2pWL/DwgoLz8YjvoLCYIwygevH+vpxk04/
1upRzoteykyL8Egon6BS8tE07ao+riIK6VcKS0dJtNBSRDIdXjDsRNCm/A76SjGw
vcKq1TjjHHuI2OiLTeGauB+5r+G+R0L8kUnvom7FeM0xdDBTss5+Wa277Jre
-----END CERTIFICATE-----
subject=CN = *.sefaz.mt.gov.br

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3599 bytes and written 380 bytes
Verification: OK
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-SHA
    Session-ID: D208D422264D4807BBD098018C95F08F0A713226B30B5303FE9717665E25409F
    Session-ID-ctx: 
    Master-Key: 167506D4C95703376589FF931D839A143381E2DFCCC8BC27D069F23310E337E4097BA15CB9277D6D44B70AEBFFBCA679
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1566304360
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---

Источник

Содержание

SSL_ERROR_SYSCALL in connection? #3517
Comments
I did this
I expected the following
i got
operating system
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection #4684
Comments
I did this
I expected the following
curl/libcurl version
curl version 7.61.1
openssl version 1.0.2k
[curl -V output]
operating system
OpenSSL SSL_connect: SSL_ERROR_SYSCALL #9566
Comments
Self-signed certificates: curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to API_IP:443 #5524
Comments
Expected behavior
Actual behavior
Information
Steps to reproduce the behavior

SSL_ERROR_SYSCALL in connection? #3517

I did this

curl -v https://www.google.com (happens with any https url)

I expected the following

i got

Uses proxy env variable https_proxy == ‘https://username:passwd@:8080’
Trying proxyip.
TCP_NODELAY set
Connected to proxyurl (proxyip) port 8080 (#0)
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
TLSv1.3 (OUT), TLS handshake, Client hello (1):
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ourProxyURL:8080
Closing connection 0

[curl -V output]
curl 7.63.0 (x86_64-pc-linux-gnu) libcurl/7.63.0 OpenSSL/1.1.1a zlib/1.2.11 libidn2/2.1.0 libpsl/0.20.2 (+libidn2/2.1.0) libssh2/1.8.0 nghttp2/1.35.1
Release-Date: 2018-12-12
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

operating system

I’m hoping someone can help. I have been trying to get this to work all day. We have to go through a corporate proxy. As you can see from the output above it is picking up my proxy settings. wget works fine but unfortunately i need curl to work. It seems to be actually failing verifying the proxys certificate not googles certificate. I wish i could just tell curl to ignore the cert error. Any help would be appreciated.

The text was updated successfully, but these errors were encountered:

Источник

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection #4684

I did this

./curl —ciphers ALL https://IP -k —> report curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection

but when i order the ALL ciphers by SSLv2, SSLv3, TLS. it’s work
And server side is IIS6.0

The SSLScan output
Supported Server Cipher(s):
Preferred TLSv1.0 128 bits RC4-MD5
Accepted TLSv1.0 128 bits RC4-SHA
Accepted TLSv1.0 112 bits DES-CBC3-SHA
Accepted TLSv1.0 56 bits DES-CBC-SHA
Preferred SSLv3 128 bits RC4-MD5
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 112 bits DES-CBC3-SHA
Accepted SSLv3 56 bits DES-CBC-SHA

the ALL string contains ‘Supported Server Cipher’

I expected the following

the ciphers list string ALL can access the https site

curl/libcurl version

curl version 7.61.1

compile options
./configure —prefix=$/curl —disable-shared —enable-static —disable-ldap —disable-ldaps —enable-ipv6 —enable-ares=$/c-ares —with-zlib=$/zlib —with-ssl=$/openssl

openssl version 1.0.2k

compile options
./config —prefix=/root/openssl1_0_2k shared zlib threads sctp enable-krb5 —with-krb5-flavor=MIT enable-weak-ssl-ciphers enable-ssl2 enable-ssl3

[curl -V output]

curl 7.61.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.61.1-DEV OpenSSL/1.0.2k zlib/1.2.7 c-ares/1.14.0
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy

operating system

CentOS Linux release 7.0

The text was updated successfully, but these errors were encountered:

curl passes the —ciphers string to OpenSSL SSL_CTX_set_cipher_list. According to their doc for ALL it should use all ciphers. What happens when you use the openssl tool?

(Replace httpbin.org with your hostname or IP. If it’s an IP then remove the -servername option.)

curl passes the —ciphers string to OpenSSL SSL_CTX_set_cipher_list. According to their doc for ALL it should use all ciphers. What happens when you use the openssl tool?

(Replace httpbin.org with your hostname or IP. If it’s an IP then remove the -servername option.)

the OpenSSl output
CONNECTED(00000003)
140291652220816:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 364 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1575916670
Timeout : 300 (sec)
Verify return code: 0 (ok)

Источник

OpenSSL SSL_connect: SSL_ERROR_SYSCALL #9566

For some reason when accessing a site load balanced with GKE on Opensuse Tumbleweed the site doesn’t load I have tested this on other devices each running older versions of openssl it seems to work fine. Ironically it works without www. but adding www. it fails to load.

Running the following commands gave me the impression it is something to do with openssl

This works fine but

gives the following;

I have tested it on Android Devices, Ubuntu Devices, OpenSuse Devices, IPhones and several different online services that test a websites availability. All devices that I can get the openssl version for that work are using an earlier version of OpenSSL.

The only device that the test failed on was my OpenSuse Tumbleweed Laptop running version OpenSSL 1.1.1c 28 May 2019

I have tested if it was the browser by using chromium, chrome, chrome-unstable, firefox they all failed which made me try the curl command instead.

The text was updated successfully, but these errors were encountered:

I am able to seeing the connection setup and the body response in both requests.

I am also able to see the connection setup in the browser too with a valid response. The browsers look like they are blocking the content because it is mixed http/https.

Hi,
I can confirme here too.
Client Win32bits with Openssl-1.1.1c, was repeatedly raising SSL_ERROR_SYSCALL with url: homologacao.sefaz.mt.gov.br
Protocol: TLS1.2
https://www.ssllabs.com/ssltest/analyze.html?d=homologacao.sefaz.mt.gov.br

Hi,
More info about SSL_ERROR_SYSCALL:
SSL Error: 0
SSL State: SSLOK
ERR: error:00000000:lib(0):func(0):reason(0)
ERR Code: 0

Its not a real bug.
homologacao.sefaz.mt.gov.br it’s closing connection, for some reason.
At first SSL_read, returns -1.
Log made with callback:
DTLS: no
protocol: TLSv1.3
cipher name: (NONE)

DTLS: no
protocol: TLSv1.3
cipher name: (NONE)
SSL_connect:before SSL initialization

DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS write client hello

DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server hello

DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server certificate

DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server key exchange

DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server done

DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS write client key exchange

DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS write change cipher spec

DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS write finished

DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS read change cipher spec

DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS read finished

DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA

SSL Error: 5
SSL State: SSLOK
ERR: error:00000005:lib(0):func(0):DH lib
ERR Code: 0
WSAError: 10054

Hi,
I think the problem here is interoperability.
The server is Tomcat and have support only for:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Openssl-1.1.1c do not have support for CBC:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA

The server is out of our access, then the solution is client suppport.
Howto configure openssl-1.1.1c to add CBC ciphers support?

You need to configure OpenSSL with “enable-weak-ssl-ciphers”

CBC mode is bad for HTTPS traffic, tell the server they need to upgrade. A good article on this is at https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/

Try using ALL not DEFAULT.

I belive thats is cause the error.
Now the question is why server is not ordering the CertificateRequest record?

Источник

Self-signed certificates: curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to API_IP:443 #5524

I have tried with the latest version of Docker Desktop
I have tried disabling enabled experimental features
I have uploaded Diagnostics
Diagnostics ID: 38E55D99-754A-49D0-AA69-B7E137F4729D/20210331135025

Expected behavior

Inside a docker container with debian:10.7 for example
Tried to kubectl get node or curl -k https://API and get response.

Actual behavior

Inside a docker container with debian:10.7 for example
Tried to kubectl get node or curl -k https://API_IP and none of them works with my GKE endpoint.

With kubectl: kubectl -v=8 get node

With curl: curl -vvv -k https://API_IP tell me this.

Information

Please, help us understand the problem. For instance:

Is it reproducible? No, since I do not want to tell my endpoint.

Is the problem new? Yes

Did the problem appear with an update? Yes

macOS Version: 11.1 (20C69)

Docker Desktop Version: 3.3.0 (62345) — Apple Silicon Tech Preview RC 2

Steps to reproduce the behavior

GKE endpoint has a certificate (automatically generated) that is not trusted by all browsers and will expire in nearly 5 years.

I have tried with curlimages/curl:latest image, also add —tls-max 1.2 to the curl command and always same issue.
I have tried this in my mac shell and it works fine.

It seems to me that something changes in the latest upgrade.

The text was updated successfully, but these errors were encountered:

This is not only M1, My 2019 MacBook Pro with Intel i9 has the same issue connecting to GKE endpoints.

I first tried different container images (ubuntu:focal, ubuntu:bionic, ubuntu:xenial, debian:buster) and differnet kubectl versions in the containers (1.21.0, 1.19.7).

The 1ms response times strongly suggests its being blocked by Docker.

I downgraded to 3.2.2 and functionality is restored:

This is also happening on my 2017 Macbook 10.15.7. downgraded to 3.2.2 to fix. Seems to break TLS to endpoints with self-generated certs.

Looking at 3.3.0 release notes wondering if this is breaking it?

Apply domain-based HTTPS proxy no_proxy rules for encrypted connections. Fixes

after downgrade to 3.2.2 now getting:

(can use curl -k now to successfully download)

@stellirin and @ajoldham are right, this is not just an M1 issue. Can we get this issue title and labels updated?

We’re seeing this occur on Intel Macs, with containers trying to call HTTPS endpoints where the cert is (ultimately) signed by an internal root CA.

Seeing a similar issue as well, running openssl s_client -showcerts -connect stackoverflow.com:443 from within the container that had the self signed certs
would indicate a handshake failure and not show any certificates, rolling back to 3.2.2 resolved this issue. Running intel mpb here with 10.15.7

Has anyone attempted this with the 3.3.1 update yet? I experience my issues with 3.3.0

Downloading the 3.3.1 «Mac with Intel Chip» from https://docs.docker.com/docker-for-mac/release-notes/ seems to be the same version as 3.3.0, and didn’t appear to fix anything for me.

Same SSL_ERROR_SYSCALL after update to 3.3.1, I can’t access my kubernetes cluster from inside of the containers. After downgrade to 3.2.2 everything works ok, but Docker Desktop forces the upgrade to latest version and there’s no way to disable automatic upgrades. Now each time I restart my mac or relaunch the Docker Desktop it gets the latest version automatically, so I need to uninstall it and reinstall 3.2.2 back.
So for time being I just launched a VM with linux and installed docker there until this is fixed.

Aye also getting this on 3.3.1 when connecting to kubernetes masters with self-signed CA’s.

Adding another data point just in case more comments = more attention 🙂

Same issue for 3.3.0 and 3.3.1 on an 16-inch Intel MacBook Pro — and yeah, it only seems to be https sites with an entirely self-signed cert and/or cert chain, as @rnorth mentioned. If the top-level cert is a well known root cert, things seem fine.

In my company’s case, this affects things like:

Our internal Kubernetes calls (i.e., with kubectl ) with servers that have just one self-signed cert.
Outgoing traffic from our corporate proxy to public places like google.com where the proxy uses its own certs for the whole chain (i.e., the root cert is owned by my company).

Found a workaround.

Run a socks5/http proxy on your bastion server or localhost (squidman).
After that, export HTTPS_PROXY=http://192.168.X.X:3333

Enough for me in the meantime.

My solution is downgrade

Uninstall docker from Docker Desktop
Move Docker to trash from finder
install version 3.2.2
https://docs.docker.com/docker-for-mac/release-notes/#docker-desktop-322

Without the first step, docker gets stuck on a factory reset

I too had to downgrade to work around this. I couldn’t use kubectl against GKE anymore from within a Docker container on my laptop, but downgrading fixed it.

Without the first step, docker gets stuck on a factory reset

If someone is still facing factory reset stuck issue despite doing step 1, modify settingsVersion in /Users/ /Library/Group Containers/group.com.docker/settings.json to 6 before running Docker 3.2.2.

I got the version automatically and ran into the problem again.
It’s too bad that you can’t turn off automatic updates.

Because the autoupdate can’t be disabled now I am stuck reinstalling every other time I start Docker for Mac.

I suppose the autoupdate function is patched to ask in the later version, but because we have to rollback, we get pushed to the latest version every time.

Reinstalling 3.2.2 and going through this https://gist.github.com/LeZuse/aad7d02d2ccc564f7fc21f032607b47b has helped me workaround the auto update on restart.
Still hours of headache. Good luck guys!

Upgrading to 3.3.2 fixed it for me 🎉

Yea 3.3.2 seems to have fixed the proxy issue for me too:

Disable the HTTP and HTTPS transparent proxies when there is no upstream proxy set. Fixes

Upgrading to 3.3.2 fixed it for me

Yea 3.3.2 seems to have fixed the proxy issue for me too:

Disable the HTTP and HTTPS transparent proxies when there is no upstream proxy set. Fixes

Did you folks do anything after the upgrade or did it work outright?

Upgrading to 3.3.2 fixed it for me

Yea 3.3.2 seems to have fixed the proxy issue for me too:

Disable the HTTP and HTTPS transparent proxies when there is no upstream proxy set. Fixes

Did you folks do anything after the upgrade or did it work outright?

For me it worked right away.

Upgrading to 3.3.2 fixed it for me

Yea 3.3.2 seems to have fixed the proxy issue for me too:

Disable the HTTP and HTTPS transparent proxies when there is no upstream proxy set. Fixes

Did you folks do anything after the upgrade or did it work outright?

Worked right away. I upgraded from the broken version to 3.2.2 and it worked. No other changes.
Had a very reproducible setup that suddenly worked

is this issue concerned with the certificate? It seems not.

A single curl command to any ip in the VPN will show error

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection

If this issue does not concern with the certificate, how about change the title of the issue?

Источник