ulidtko commented on pull request #2197:
URL: https://github.com/apache/thrift/pull/2197#issuecomment-671082263
Whew, what a ride! Diving into Erlang is joy.
I did a bit of testing on this... Except for the fiddly setup and a few
deprecation-updates needed, the Erlang library looks mostly functional. All
unit-tests under `lib/erl/test` pass (well, after you've had enough fun with
the setup required to run them).
I also run the Erlang client on **OTP 23** against some implementations,
including the Java server from the cross-test suite. Findings:
* The Erlang client does connect to `openssl s_server` using TLS1.2.
* The Erlang client does connect to `openssl s_server` using TLS1.3.
* The Erlang client does connect to `openssl s_server` using TLS1.2 with
client cert required (`-Verify 2`).
* The Erlang client does connect to `openssl s_server` using TLS1.3 with
client cert required (`-Verify 2`).
* The Erlang client **does not** connect to `socat -
openssl-listen:9008,cert=test/keys/server.pem,cafile=test/keys/CA.pem` despite
using the very same OpenSSL; error produced:
socat[1847925] E SSL_accept(): error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed
I tend to think it's a bug in how `socat` instructs the openssl API to
verify client certs. Didn't investigate this deeper.
* The Java cross-test server [on git master] claims to only support
**TLS1.3**:
Which is [really really
weird](https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/). I'm not
sure this is intentional. Somebody needs to check this. @zeshuai007 please see
above; bytes on the wire directly contradict your claim *"the Java server uses
TLS1.2 by default and does not support TLS1.3"*. It shows the opposite: TLS1.3
*only* is advertised by the Java server. I'm running `openjdk version "11.0.8"
2020-07-14`.
* You can run a section of the Thrift cross-test suite (a.k.a. "Apache
Thrift - Integration Test Suite") directly:
./test.py --server java --client erl --regex ip-ssl
This runs in ~20 seconds. Still way faster than waiting many basketball
games for Travis to run it. :wink:
* Finally: the TLS 1.3 connection from Erlang client to Java server **does
not** go well indeed. Here's a debug dump from Erlang side:
[java-erl-tls1.3_client.log](https://github.com/apache/thrift/files/5048136/java-erl_binary_buffered-ip-ssl_client.log).
It appears that the Java server is doing something that makes the Erlang
client crash :/
Anyhow, **all tests pass** if I restrict Erlang to only TLS 1.2 & TLS
1.1:
```
ulidtko@pasocon ~/s/t/test (master)> ./test.py --server java --client erl
Apache Thrift - Integration Test Suite
Sun Aug 09 20:37:26 2020
===============================================================================
server-client: protocol: transport:
result:
java-erl binary buffered-ip
success
java-erl binary fastframed-framed-ip
success
java-erl binary framed-ip
success
java-erl binary fastframed-framed-ip-ssl
success
java-erl binary framed-ip-ssl
success
java-erl binary buffered-ip-ssl
success
java-erl multic-compact framed-ip
success
java-erl multic-compact buffered-ip
success
java-erl multic-compact framed-ip-ssl
success
java-erl multic-compact buffered-ip-ssl
success
java-erl multic-compact fastframed-framed-ip
success
java-erl multic-compact fastframed-framed-ip-ssl
success
java-erl multi-binary framed-ip
success
java-erl multi-binary buffered-ip
success
java-erl multi-binary fastframed-framed-ip
success
java-erl multi-binary framed-ip-ssl
success
java-erl multi-binary buffered-ip-ssl
success
java-erl multi-binary fastframed-framed-ip-ssl
success
java-erl compact framed-ip
success
java-erl compact framed-ip-ssl
success
java-erl compact buffered-ip
success
java-erl compact fastframed-framed-ip
success
java-erl compact buffered-ip-ssl
success
java-erl compact fastframed-framed-ip-ssl
success
===============================================================================
No unexpected failures.
```
... Which is be done by passing `-ssl protocol_version "['tlsv1.2',
'tlsv1.1']"` to the `erl` invocation.
---------------------
Amusingly, the very same Java server which says it only speaks TLS1.3 to
TLS1.3 clients — suddenly starts talking TLS1.2 just fine, to a non-tls13
client. What a mess!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
