Re: How to configure encryption ciphers and SSL/TLS protocols

2014-06-09 Thread John Cox
Hi

That's not correct no, I get plenty of TLS 1.0 trafic and it has been
the case for many years

To parrot this on all of my various instances OpenSMTPD and not I get tons
of TLS 1.0 and SSLv3 traffic, I wish I didn't but it still happens. Heck
every now and again I see SSLv2 attempts which for most of my instances get
killed. I haven't seen one on my OpenSMTPD instance yet but its only time.
But seriously for email any transport encryption is better than none and
OpenSMTPD's default should be the best way to handle opportunistic TLS
where you always try to use the highest protocol version supported with the
best ciphers supported, and there shouldnt need to be a knob for it.

Whilst I agree with what you are saying for general purpose mail
servers, I can see applications where enforced encryption levels are
worth having.  I can see that some company gateways, where they know
all of the other endpoints, might wish to enforce appropriate
encryption as everybody who should be talking to that MTA should be
capable of it and anything else is therefore spam or hacking.  This is
particularly plausible on any link where TLS or SSL is already
mandatory.

Regards

JC

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: How to configure encryption ciphers and SSL/TLS protocols

2014-06-09 Thread Gilles Chehade
On Mon, Jun 09, 2014 at 08:39:52AM +0100, John Cox wrote:
 Hi
 
 That's not correct no, I get plenty of TLS 1.0 trafic and it has been
 the case for many years
 
 To parrot this on all of my various instances OpenSMTPD and not I get tons
 of TLS 1.0 and SSLv3 traffic, I wish I didn't but it still happens. Heck
 every now and again I see SSLv2 attempts which for most of my instances get
 killed. I haven't seen one on my OpenSMTPD instance yet but its only time.
 But seriously for email any transport encryption is better than none and
 OpenSMTPD's default should be the best way to handle opportunistic TLS
 where you always try to use the highest protocol version supported with the
 best ciphers supported, and there shouldnt need to be a knob for it.
 
 Whilst I agree with what you are saying for general purpose mail
 servers, I can see applications where enforced encryption levels are
 worth having.  I can see that some company gateways, where they know
 all of the other endpoints, might wish to enforce appropriate
 encryption as everybody who should be talking to that MTA should be
 capable of it and anything else is therefore spam or hacking.  This is
 particularly plausible on any link where TLS or SSL is already
 mandatory.
 

please define enforced encryption levels ?

pretty much anyone tweaking ssl_ciphers will actually downgrade security
or/and break interop with other servers. some people may know how to tie
things further for their specific use-cases but the minute we add a knob
other people will start using it and shoot themselves in the foot.

At the time being we're looking to is to have the bul0k of users safe by
default and we're looking for more:

   https://twitter.com/Mayeu/status/474109854651785216

the magic of OpenSMTPD, you do no TLS configuration and you're graded A
 by default 3  (test here: starttls.info)

Im not saying that this will hold true forever but at this point in time
I would prefer that we dont have ssl_ciphers and that any improvement we
do is made to the default until we exhausted all possibilities to do so.


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: How to configure encryption ciphers and SSL/TLS protocols

2014-06-09 Thread Adam Suhl
I think at build time you can fine-tune which ciphers you want by editing 
ssl.h -- in particular the SSL_CIPHERS define.
--Adam

On Mon, 9 Jun 2014, Gilles Chehade wrote:

 On Mon, Jun 09, 2014 at 08:39:52AM +0100, John Cox wrote:
  Hi
  
  That's not correct no, I get plenty of TLS 1.0 trafic and it has been
  the case for many years
  
  To parrot this on all of my various instances OpenSMTPD and not I get tons
  of TLS 1.0 and SSLv3 traffic, I wish I didn't but it still happens. Heck
  every now and again I see SSLv2 attempts which for most of my instances get
  killed. I haven't seen one on my OpenSMTPD instance yet but its only time.
  But seriously for email any transport encryption is better than none and
  OpenSMTPD's default should be the best way to handle opportunistic TLS
  where you always try to use the highest protocol version supported with the
  best ciphers supported, and there shouldnt need to be a knob for it.
  
  Whilst I agree with what you are saying for general purpose mail
  servers, I can see applications where enforced encryption levels are
  worth having.  I can see that some company gateways, where they know
  all of the other endpoints, might wish to enforce appropriate
  encryption as everybody who should be talking to that MTA should be
  capable of it and anything else is therefore spam or hacking.  This is
  particularly plausible on any link where TLS or SSL is already
  mandatory.
  
 
 please define enforced encryption levels ?
 
 pretty much anyone tweaking ssl_ciphers will actually downgrade security
 or/and break interop with other servers. some people may know how to tie
 things further for their specific use-cases but the minute we add a knob
 other people will start using it and shoot themselves in the foot.
 
 At the time being we're looking to is to have the bul0k of users safe by
 default and we're looking for more:
 
https://twitter.com/Mayeu/status/474109854651785216
 
 the magic of OpenSMTPD, you do no TLS configuration and you're graded A
  by default 3  (test here: starttls.info)
 
 Im not saying that this will hold true forever but at this point in time
 I would prefer that we dont have ssl_ciphers and that any improvement we
 do is made to the default until we exhausted all possibilities to do so.
 
 
 -- 
 Gilles Chehade
 
 https://www.poolp.org  @poolpOrg
 
 -- 
 You received this mail because you are subscribed to misc@opensmtpd.org
 To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
 
 

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org