SSL_ERROR_SYSCALL in connection to www.example.com:443

[shanecurran]

Hi there,

I'm having issues getting the TLS mitm proxy up and running on Mac.

Running the test_against_curl.sh script and also calling the proxy directly using cURL yields the following output:

Shanes-MacBook-Pro:third-wheel shane$ curl -x http://127.0.0.1:8080 https://google.com:443 -vv --http1.1 --cacert ./ca/ca_certs/cert.pem -L
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.64.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: ./ca/ca_certs/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to google.com:443
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to google.com:443

Do you know if there's a configuration issue with the latest version of Rust/Tokio? Or am I just running something incorrectly :)

Thank you!

[campbellC]

Hi Shane,

Can you confirm that you’ve run the setup_and_validate_environment script? If so I’ll dig out my old Mac and give this a go.

Cheers, Chris

[shanecurran]

Thanks for the reply @campbellC — after some debugging, I got to the bottom of it and found an issue with the native-tls crate where it has issues with DER-encoded keys on Mac as part of the Identity struct.

See here: https://github.com/sfackler/rust-native-tls/issues/104

Edit: wrong issue — https://github.com/sfackler/rust-native-tls/issues/19

[campbellC]

Understood. The bit of third-wheel that depends on that piece of native Tls actually has a TODO on it to figure out a better way of creating ad hoc identities IIRC. This issue should exist to close out that TODO or until a fix comes upstream. Thanks for reporting

[campbellC]

Began looking into this and it’s actually around more than just the der format issue: there’s also some failures relating to the use of authority key identifier. That’s part of the x509 spec I don’t know well so I’m going to dig in there and learn a thing or two before a fix will come in.

In the meantime, third-wheel is working for me on Ubuntu so suggest you try it out in docker images if you would like - the testing against browser scripts do this.

[campbellC]

This page explains authority key identifier. Importantly it seems to suggest that since the CA used in third-wheel uses self-signed certificates there is no need to have the authority key identifier at all anyway.

[campbellC]

It turns out the issue is that mac requires a passphrase and encryption on key files. This turned out to be a little bit annoying to put everywhere and eventually we need to allow clients to pass in their own passphrase (since we allow them to pass in their own key and cert file) but for now I've just hardcoded a dummy passphrase. Commit with fix here.

@shanecurran if you pull up to date on master it should now work - it's working for me on my mac at least (although thats at least one OS update behind). Please do reopen with more logging if there's still an issue. Thanks for the first bug report on the repo :)