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

Conversation

Projects
None yet
2 participants
@remyabel
Copy link
Contributor

remyabel commented Feb 25, 2019

Fixes #24

remyabel added some commits Feb 25, 2019

@imthenachoman

This comment has been minimized.

Copy link
Owner

imthenachoman commented Feb 26, 2019

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.

@remyabel

This comment has been minimized.

Copy link
Contributor Author

remyabel 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

This comment has been minimized.

Copy link
Owner

imthenachoman commented Feb 27, 2019

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

This comment has been minimized.

Copy link
Owner

imthenachoman commented Feb 27, 2019

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

@remyabel

This comment has been minimized.

Copy link
Contributor Author

remyabel 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
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.