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

elli_tcp: cast 'accepted' AFTER TLS handshake succeeded #90

Merged
merged 2 commits into from
Nov 25, 2020

Conversation

sg2342
Copy link
Contributor

@sg2342 sg2342 commented Sep 26, 2020

fix #84

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.03%) to 75.787% when pulling c919553 on sg2342:fix_tls_accept_logic into 968afee on elli-lib:main.

@coveralls
Copy link

coveralls commented Sep 26, 2020

Coverage Status

Coverage increased (+0.7%) to 76.471% when pulling d6f6d50 on sg2342:fix_tls_accept_logic into 968afee on elli-lib:main.

@yurrriq
Copy link
Member

yurrriq commented Sep 30, 2020

Thanks. This looks good to me. Would you be willing to add a test or two? Ideally they would fail before this patch and succeed after.

@sg2342
Copy link
Contributor Author

sg2342 commented Sep 30, 2020

Thanks. This looks good to me. Would you be willing to add a test or two? Ideally they would fail before this patch and succeed after.

Not done yet. I have to find a solution for OTP-20 and older where ssl:connect/3 in acceptor_leak_regression succeeds despite the verify and verify_fun options.

@sg2342
Copy link
Contributor Author

sg2342 commented Sep 30, 2020

OTP-20 and older reuse TLS sessions even when the (verify) connect options have changed. Since other successful tests might leave a reusable TLS session, one has to set reuse_sessions false to provoke the CLIENT ALERT needed to trigger the bug.

elli_ssl_tests:acceptor_leak_regression/0 will succeed (on all supported OTP releases) with the fixed elli_tcp accept logic. It will fail (on all supported OTP releases) without the fix.

BTW: rebar3 does start ssl by default which is why the application:start/1 and application:stop/1 calls in elli_ssl_tests are unnecessary. Removing them reduces the error_logger output of elli_ssl_tests
from

=INFO REPORT==== 30-Sep-2020::23:02:01 ===
TLS client: In state certify at ssl_handshake.erl:1293 generated CLIENT ALERT: Fatal - Bad Certificate

=ERROR REPORT==== 30-Sep-2020::23:02:01 ===
Elli request (pid #Port<0.72536>) unexpectedly crashed:
shutdown

=ERROR REPORT==== 30-Sep-2020::23:02:01 ===
Elli request (pid <0.1649.0>) unexpectedly crashed:
{shutdown,{gen_statem,call,[<0.1687.0>,{recv,0,60000},infinity]}}

=INFO REPORT==== 30-Sep-2020::23:02:01 ===
TLS server: In state certify received CLIENT ALERT: Fatal - Bad Certificate


=INFO REPORT==== 30-Sep-2020::23:02:01 ===
    application: ssl
    exited: stopped
    type: temporary

=INFO REPORT==== 30-Sep-2020::23:02:01 ===
    application: public_key
    exited: stopped
    type: temporary


=INFO REPORT==== 30-Sep-2020::23:02:01 ===
    application: crypto
    exited: stopped
    type: temporary

to

=NOTICE REPORT==== 30-Sep-2020::23:21:13.058984 ===
TLS client: In state wait_cert_cr at ssl_handshake.erl:1948 generated CLIENT ALERT: Fatal - Bad Certificate

=NOTICE REPORT==== 30-Sep-2020::23:21:13.059186 ===
TLS server: In state wait_finished received CLIENT ALERT: Fatal - Bad Certificate

@yurrriq
Copy link
Member

yurrriq commented Oct 1, 2020

BTW: rebar3 does start ssl by default which is why the application:start/1 and application:stop/1 calls in elli_ssl_tests are unnecessary. Removing them reduces the error_logger output of elli_ssl_tests

Maybe we should prefer application:ensure_started/1 and remove the application:stop/1 calls.

@yurrriq
Copy link
Member

yurrriq commented Nov 17, 2020

I say we merge this and patch the application start/stop shortly after. I'll add this to my Wednesday evening session too heh

@yurrriq
Copy link
Member

yurrriq commented Nov 21, 2020

This looks good to me, and I've confirmed elli_ssl_tests:acceptor_leak_regression/0 fails on the main branch, and succeeds with c919553.

Given that rebar3 starts crypto, asn1, public_key, and ssl, perhaps we ought not bother starting (and stopping) them.

What do you think, @tsloughter?

@tsloughter
Copy link
Member

Using ensure_all_started and not stopping those particular apps is probably a good idea.

I've wanted to move tests to Common Test since I think it has much clearer semantics for all this (and better error messages for where a failure happened in the tests).. but it would be a lot of work probably.

@tsloughter
Copy link
Member

Maybe I'll start with adding a common test suite and over time cases can be moved to it.

@yurrriq
Copy link
Member

yurrriq commented Nov 25, 2020

Merging this for now then, and we can handle the move to CT in another (series of) PR(s). Thanks, @sg2342!

@yurrriq yurrriq merged commit dba9b09 into elli-lib:main Nov 25, 2020
@sg2342 sg2342 deleted the fix_tls_accept_logic branch November 26, 2020 03:46
This was referenced Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

failed TLS handshakes spawn new acceptors
4 participants