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

Add information on how to use implicit TLS #26

Merged
merged 3 commits into from Mar 2, 2019
Merged

Add information on how to use implicit TLS #26

merged 3 commits into from Mar 2, 2019

Conversation

ghost
Copy link

@ghost ghost commented Feb 25, 2019

Fixes #24

@imthenachoman
Copy link
Owner

Something is fishy. I deleted the cert files to see what would happen and the e-mail still went through. I will have to play with this some more.

@ghost
Copy link
Author

ghost commented Feb 26, 2019

Deleting the certs won't prevent the mail from going through, but there won't be any encryption I don't think. Here's what I get with openssl s_client -connect localhost:465 before/after deleting the certs:

CONNECTED(00000003)
depth=0 C = US, CN = localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, CN = localhost
verify return:1
# etc...

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
# etc...

@imthenachoman
Copy link
Owner

So according to tcpdump, it does look like this makes the request through 465. It fails if openssl is not installed. And it works after openssl is installed even before a cert is created. But to your point, it would still work but wouldn't be encrypted. I will investigate how to confirm if it is being encrypted.

This is great stuff by the way. Thank you so much!

@imthenachoman
Copy link
Owner

sendmail -v shows some interesting details. Will investigate more.

@ghost
Copy link
Author

ghost commented Feb 27, 2019

Using swaks these are my results:

remyabel@instance-1:~$ sudo swaks --protocol smtps -tlsc --tls-cert /etc/exim4/exim.crt --tls-key /etc/exim4/exim.key -q HELO -s localhost
=== Trying localhost:465...
=== Connected to localhost.
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS local DN="/C=US/CN=localhost"
=== TLS peer DN="/C=US/CN=localhost"
# ...snip
remyabel@instance-1:~$ sudo swaks --protocol smtps -tlsc --tls-cert /etc/exim4/exim.crt --tls-key /etc/exim4/exim.key -q HELO -s localhost:25
=== Trying localhost:25...
=== Connected to localhost.
*** TLS startup failed (connect(): error:1408F10B:SSL routines:ssl3_get_record:wrong version number)

tlsc means TLS on connect. So it demonstrates that it does do TLS on port 465 and refuses to connect on port 25. If we do sudo swaks --protocol smtp -q HELO -s localhost, then it will do unencrypted transport on port 25 if for some reason someone wants to do that.

Note: if swaks refuses to connect, make sure to reconfigure exim4 to listen on 127.0.0.1; ::1 for ipv6.

@imthenachoman imthenachoman merged commit 69c8b34 into imthenachoman:master Mar 2, 2019
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.

2 participants