Which further options are needed for (start)TLS

Use this forum if you want to suggest a new feature to hMailServer. Before posting, please search the forum to confirm that it has not already been suggested.
Post Reply

Which further options are needed for (start)TLS

Force encryption (in-/outgoing startTLS)
5
23%
Force server cert validation (outgoing startTLS + TLS)
6
27%
Determine allowed cipher suites (in-/outgoing startTLS + TLS)
10
45%
An option the author has forgotten (I will describe it below)
1
5%
No more options, everything is perfect
0
No votes
 
Total votes: 22

prisma
Senior user
Senior user
Posts: 310
Joined: 2010-07-09 13:16

Which further options are needed for (start)TLS

Post by prisma » 2014-03-04 16:08

The last poll has shown that outgoing startTLS is required. To give the discussions within this forum more substance I'm interested in your opinion. What do you think? Which further options are needed for startTLS?

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-03-04 20:10

It has been established all of those are DESIRED. The part you are missing is WHAT TO DO IN THE EVENT IT FAILS???
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-03-05 00:44

Bill48105 wrote:It has been established all of those are DESIRED. The part you are missing is WHAT TO DO IN THE EVENT IT FAILS???
Inbound mail: if TLS is not used by remote server, then refuse mail, return error message to remote and close connection.

I don't know if it's possible (or even if it makes sense) to force TLS on only some remote hosts, and allow non TLS from everywhere else. For example, if your bank sends you emails then refuse the message if TLS is not used, but allow non-TLS mail from everywhere else.

Outbound mail: if TLS is not available or remote server cert can't be verified, then do not send but return error message to sender.

If we want to be fancy, we can set up outbound TLS config settings like this:
http://www.google.com/support/enterpris ... ml#3370078

A simple alternative to let hMail know that I want secure delivery is to include a special BCC recipient in the email, eg (secure@mydomain.com). This special bcc can be a config setting to flag emails for secure delivery only (the server would then ignore the bcc). Again, if the email can not be sent securely, then bounce it.

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-03-05 01:21

With respect to cipher suites selection, this should be easy to implement. In OpenSSL this is just a string that can be read from a config file (see _SSL_CTX_set_cipher_list). Here is the string I use on my web server:
"AES256-GCM-SHA384:AES128-GCM-SHA256:!RC4-SHA:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:3DES:!LOW:MEDIUM:HIGH:!aNULL:!eNULL:!ADH:!CAMELLIA:!SEED:!MD5:!EXP:!DES:!IDEA"

also, the server should be configured to use the server's cipher preferences instead of the client preferences (see SSL_OP_CIPHER_SERVER_PREFERENCE)

User avatar
mattg
Moderator
Moderator
Posts: 20538
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Which further options are needed for (start)TLS

Post by mattg » 2014-03-05 02:04

braniak wrote:Inbound mail: if TLS is not used by remote server, then refuse mail, return error message to remote and close connection.

Outbound mail: if TLS is not available or remote server cert can't be verified, then do not send but return error message to sender.
I think that you would end up with no mail pretty quickly doing this. I expect that you could still send mail normally that wasn't flagged with the secret BCC and that would allow most outgoing mail. But how does a BCC address correlate to incoming mail?

Certainly if I rejected all inbound mail that wasn't STARTTLS, I'd receive NO mail.

I understand the ideal, I'm just NOT sure of it's practicality.
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-03-05 03:52

mattg wrote:
braniak wrote:Inbound mail: if TLS is not used by remote server, then refuse mail, return error message to remote and close connection.

Outbound mail: if TLS is not available or remote server cert can't be verified, then do not send but return error message to sender.
I think that you would end up with no mail pretty quickly doing this. I expect that you could still send mail normally that wasn't flagged with the secret BCC and that would allow most outgoing mail. But how does a BCC address correlate to incoming mail?

Certainly if I rejected all inbound mail that wasn't STARTTLS, I'd receive NO mail.

I understand the ideal, I'm just NOT sure of it's practicality.
+1
Talk about breaking RFC braniak! No way we would force tls on incoming port 25 that's just nuts.. Unless there is an RFC that states it you're asking for problems starting with receiving no mail as mattg says but getting blacklisted for not being rfc compliant on standard ports. An OPTION to do that on an alternate port is one thing but no way on 25.
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-03-05 03:54

braniak wrote:With respect to cipher suites selection, this should be easy to implement. In OpenSSL this is just a string that can be read from a config file (see _SSL_CTX_set_cipher_list). Here is the string I use on my web server:
"AES256-GCM-SHA384:AES128-GCM-SHA256:!RC4-SHA:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:3DES:!LOW:MEDIUM:HIGH:!aNULL:!eNULL:!ADH:!CAMELLIA:!SEED:!MD5:!EXP:!DES:!IDEA"

also, the server should be configured to use the server's cipher preferences instead of the client preferences (see SSL_OP_CIPHER_SERVER_PREFERENCE)
Right that's the plan. I already promised prisma a new build with just that, an ini setting to specify cipher list but was surprised by my daughter being born a month early & not had time. I already know what needs to be done as I had looked over the code in advance I just need to do the changes & post up a test build. I assume you'll be ready to test too. :)
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-03-05 03:59

braniak wrote:
Bill48105 wrote:It has been established all of those are DESIRED. The part you are missing is WHAT TO DO IN THE EVENT IT FAILS???
Inbound mail: if TLS is not used by remote server, then refuse mail, return error message to remote and close connection.

I don't know if it's possible (or even if it makes sense) to force TLS on only some remote hosts, and allow non TLS from everywhere else. For example, if your bank sends you emails then refuse the message if TLS is not used, but allow non-TLS mail from everywhere else.

Outbound mail: if TLS is not available or remote server cert can't be verified, then do not send but return error message to sender.

If we want to be fancy, we can set up outbound TLS config settings like this:
http://www.google.com/support/enterpris ... ml#3370078

A simple alternative to let hMail know that I want secure delivery is to include a special BCC recipient in the email, eg (secure@mydomain.com). This special bcc can be a config setting to flag emails for secure delivery only (the server would then ignore the bcc). Again, if the email can not be sent securely, then bounce it.
Already replied to your inbound suggestion in response to mattg's response but as far as outbound a special bcc might be an option although not ideal in terms of user-friendliness lol Since i am not away of an common option in email clients (like read receipts or priority) to use bcc might be the only real way to do it on a per-email basis. Another option is to add events so that in scripts you could decide & act on it which is quite likely the route I'd go since as much as I hate adding events (it's a pain and monks up backward compatibility) we like to keep hmail LEAN and that means not having crap built in that can be done in extensions like rules/scripts. I seriously thing people will want way too many possible combinations of options & actions to justify building it into hmail & instead I'd rather put the basic building blocks in along with event & then you can do whatever the hell you want with it :)
Bill
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-03-05 15:44

Bill48105 wrote:Talk about breaking RFC braniak! No way we would force tls on incoming port 25 that's just nuts.. Unless there is an RFC that states it you're asking for problems starting with receiving no mail as mattg says but getting blacklisted for not being rfc compliant on standard ports. An OPTION to do that on an alternate port is one thing but no way on 25.
What I'm suggesting is to have config settings to force TLS for inbound mail on only some domains. For example, if incoming mail is from "*@chase.com", then return error if connections is not encrypted. As per RFC5321, section 3.3:
-------------
The first step in the procedure is the MAIL command.

MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see Section 4.2 for a discussion of error reporting). If accepted, the SMTP server returns a "250 OK" reply. If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later).

-------------
I don't think my suggestions breaks RFC.

In addition if you continue reading section 3.3, you can even reply with a 250 (to accept the MAIL FROM) and then fail with a 550 or 553 after a "RCPT TO". That means that you can reject the mail if the connection is not encrypted when the recipient matches a config setting. For example, if you give all of your banks the same (special) email address (eg. secure@mydomain.com), then you can reject only those (non-encrypted) emails that are sent to secure@mydomain.com. This is all done BEFORE any sensitive data (the email body) is transmitted.

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-03-05 15:53

Bill48105 wrote:Right that's the plan. I already promised prisma a new build with just that, an ini setting to specify cipher list but was surprised by my daughter being born a month early & not had time. I already know what needs to be done as I had looked over the code in advance I just need to do the changes & post up a test build. I assume you'll be ready to test too. :)
Congrats on the birth :-)
Yes, I will be able to test it. Thank you!

napertox
New user
New user
Posts: 2
Joined: 2014-04-23 09:18

Re: Which further options are needed for (start)TLS

Post by napertox » 2014-04-23 09:32

Hi all,

my Option was "An option the author has forgotten".

I would be very helpfull if i can see the Parameter i wrote to the action rule.
The screenshot in the attachment explain, what i am talking about.

Thanks for this great program.

greetings Andy
Attachments
Rule_Forum20140423.png
only forward mail is the visible parameter, but not the parameter itself.
Rule_Forum20140423.png (9.63 KiB) Viewed 10070 times

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-04-23 10:19

braniak wrote:
Bill48105 wrote:Right that's the plan. I already promised prisma a new build with just that, an ini setting to specify cipher list but was surprised by my daughter being born a month early & not had time. I already know what needs to be done as I had looked over the code in advance I just need to do the changes & post up a test build. I assume you'll be ready to test too. :)
Congrats on the birth :-)
Yes, I will be able to test it. Thank you!
Sorry just saw this. Thanks! :)
Btw I posted up the special SSL option & cipher settings build if you are interested. no new starttls stuff though yet sorry busy.
Bill
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-04-23 10:21

napertox wrote:Hi all,

my Option was "An option the author has forgotten".

I would be very helpfull if i can see the Parameter i wrote to the action rule.
The screenshot in the attachment explain, what i am talking about.

Thanks for this great program.

greetings Andy
Why did you post this here Andy? This thread is about starttls development. :)
But yes I agree it is annoying the value can not be seen without editing it.
Bill
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

napertox
New user
New user
Posts: 2
Joined: 2014-04-23 09:18

Re: Which further options are needed for (start)TLS

Post by napertox » 2014-04-23 10:25

Bill48105 wrote:
napertox wrote:Hi all,

my Option was "An option the author has forgotten".

I would be very helpfull if i can see the Parameter i wrote to the action rule.
The screenshot in the attachment explain, what i am talking about.

Thanks for this great program.

greetings Andy
Why did you post this here Andy? This thread is about starttls development. :)
But yes I agree it is annoying the value can not be seen without editing it.
Bill
Hi Bill.

upps. i only searched about a wishlist :) Sorry about that. Maybe some of the admins or moderators can move my post to the right place.

Thanks.

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-04-23 16:16

Bill48105 wrote: Btw I posted up the special SSL option & cipher settings build if you are interested. no new starttls stuff though yet sorry busy.
Where did you post this? The latest experimental build I see is:
2014-04-08 5.4-B2014040801

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-04-23 16:49

braniak wrote:
Bill48105 wrote: Btw I posted up the special SSL option & cipher settings build if you are interested. no new starttls stuff though yet sorry busy.
Where did you post this? The latest experimental build I see is:
2014-04-08 5.4-B2014040801
Hello braniak.
Since it is (was) highly experimental & at the time untested (I have since confirmed options & cipher options do indeed change with the settings, at least for incoming) I did not want to post it like the rest. It is posted at the end of the Experimental thread or in the thread discussing it:
http://www.hmailserver.com/forum/viewto ... 24#p160724
Bill
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-04-23 17:17

Bill48105 wrote: Since it is (was) highly experimental & at the time untested (I have since confirmed options & cipher options do indeed change with the settings, at least for incoming) I did not want to post it like the rest. It is posted at the end of the Experimental thread or in the thread discussing it:
http://www.hmailserver.com/forum/viewto ... 24#p160724
Thank you Bill. I will download and install in the next day or so.

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-04-23 22:25

Bill48105 wrote: Since it is (was) highly experimental & at the time untested (I have since confirmed options & cipher options do indeed change with the settings, at least for incoming) I did not want to post it like the rest. It is posted at the end of the Experimental thread or in the thread discussing it:
http://www.hmailserver.com/forum/viewto ... 24#p160724
I'm currently running the following hMail build: 5.4-B2014040801-ssldyn (using dynamic OpenSSL DLL's)

Is the build you posted compiled to load OpenSSL DLL's at runtime? If not, please make this the default in all future builds since this will allow users to upgrade OpenSSL without changing the hMail exe.

Also, what are the various options that can be specified in SSLOptionList? Would this work?
SSLOptionList=default_workarounds,no_sslv2,cipher_server_preference,no_session_resumption_on_renegotiation

Additionally, is there a way to specify SSL_CTX_set_verify_depth?

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-04-24 03:16

braniak wrote:
Bill48105 wrote: Since it is (was) highly experimental & at the time untested (I have since confirmed options & cipher options do indeed change with the settings, at least for incoming) I did not want to post it like the rest. It is posted at the end of the Experimental thread or in the thread discussing it:
http://www.hmailserver.com/forum/viewto ... 24#p160724
I'm currently running the following hMail build: 5.4-B2014040801-ssldyn (using dynamic OpenSSL DLL's)

Is the build you posted compiled to load OpenSSL DLL's at runtime? If not, please make this the default in all future builds since this will allow users to upgrade OpenSSL without changing the hMail exe.

Also, what are the various options that can be specified in SSLOptionList? Would this work?
SSLOptionList=default_workarounds,no_sslv2,cipher_server_preference,no_session_resumption_on_renegotiation

Additionally, is there a way to specify SSL_CTX_set_verify_depth?

OK cool glad that special build work for you. I had only made it because I wasn't sure if my emergency build was going to work or not but also because it had been brought up. I MIGHT consider posting alternate builds from time to time but it is a lot more work since OPENSSL needs to be compiled 1st using different tools than hmail. It was a big hassle even getting that one built. I highly doubt hmail will ever be released that way though for many reasons. Biggest is the DLL HELL that awaits depending on what else uses it on the system but also it's one more thing to have to support people on when they break it using their own dll (kind of like how mysql dll is such a pain especially for 64bit users & explaining why 32bit dll is needed). Plus if people upgrade hmail they might be lazy & leave an old vulnerable dll. etc etc. So yeah I can see the merits of wanting the option so we'll see.

Sorry I need to update the post with available options. Unfortunately hmail uses boost to interface with openssl & it seems not all options are supported. None of the ones you listed are supported except default_workarounds & no_sslv2. I'll get the post updated there is only 1 more than what I posted anyway.
Bill
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

braniak
Normal user
Normal user
Posts: 33
Joined: 2014-02-08 18:21

Re: Which further options are needed for (start)TLS

Post by braniak » 2014-04-24 04:31

Bill48105 wrote: OK cool glad that special build work for you. I had only made it because I wasn't sure if my emergency build was going to work or not but also because it had been brought up. I MIGHT consider posting alternate builds from time to time but it is a lot more work since OPENSSL needs to be compiled 1st using different tools than hmail. It was a big hassle even getting that one built. I highly doubt hmail will ever be released that way though for many reasons. Biggest is the DLL HELL that awaits depending on what else uses it on the system but also it's one more thing to have to support people on when they break it using their own dll (kind of like how mysql dll is such a pain especially for 64bit users & explaining why 32bit dll is needed). Plus if people upgrade hmail they might be lazy & leave an old vulnerable dll. etc etc. So yeah I can see the merits of wanting the option so we'll see.
I don't think you need to spend any time to generate OpenSSL binaries since they are available on the web including here: http://slproweb.com/products/Win32OpenSSL.html - in fact, I'm not using the DLL's that you created for hMail.

As far as DLL hell; the way I deal with it is to copy the DLL's into the same folder where the app exe is located. I do this with my web server as well as hMail. The advantage of separate DLL's for a common library like OpenSSL is that if there is a serious vulnerability (like heartbleed), we don't need to wait for you to recompile the entire app.

Bill48105
Developer
Developer
Posts: 6192
Joined: 2010-04-24 23:16
Location: Michigan, USA

Re: Which further options are needed for (start)TLS

Post by Bill48105 » 2014-04-24 07:09

braniak wrote:
Bill48105 wrote: OK cool glad that special build work for you. I had only made it because I wasn't sure if my emergency build was going to work or not but also because it had been brought up. I MIGHT consider posting alternate builds from time to time but it is a lot more work since OPENSSL needs to be compiled 1st using different tools than hmail. It was a big hassle even getting that one built. I highly doubt hmail will ever be released that way though for many reasons. Biggest is the DLL HELL that awaits depending on what else uses it on the system but also it's one more thing to have to support people on when they break it using their own dll (kind of like how mysql dll is such a pain especially for 64bit users & explaining why 32bit dll is needed). Plus if people upgrade hmail they might be lazy & leave an old vulnerable dll. etc etc. So yeah I can see the merits of wanting the option so we'll see.
I don't think you need to spend any time to generate OpenSSL binaries since they are available on the web including here: http://slproweb.com/products/Win32OpenSSL.html - in fact, I'm not using the DLL's that you created for hMail.

As far as DLL hell; the way I deal with it is to copy the DLL's into the same folder where the app exe is located. I do this with my web server as well as hMail. The advantage of separate DLL's for a common library like OpenSSL is that if there is a serious vulnerability (like heartbleed), we don't need to wait for you to recompile the entire app.

Umm the problem is none of the pre-builts have the libs! They are just dll's. ;( The libs are needed to BUILD hmail where the dll's are needed to RUN. Plus there were ZERO pre-built for windows during the heartbleed thing so I was forced to build from source or wait for no idea how long.

As far as dll hell I mean if you have multiple openssl dll's on the system that are not the same version. Or if someone doesn't put it in right folder & it finds who knows which dll in which folder in search path. It's just a big headache to support. Like I said I offered to SOMETIMES post up a dynamic built one but can't say how often.

Btw I totally agree & understand it would be handy to be able to drop in your own DLL. The question is do the pros outweigh the cons for the general user and the likelihood zero day vulnerabilities might ever crop up again or how often.
hMailServer build LIVE on my servers: 5.4-B2014050402
#hmailserver on FreeNode IRC https://webchat.freenode.net/?channels=#hmailserver
*** ABSENT FROM hMail! Those in IRC know how to find me if urgent. ***

Post Reply