On Mon, 9 Jun 2014 10:16:43 +0200, you 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" ? Tricky - I don't have a specific use case in mind, but I worked on building a military email system (X.400 based - it was that long ago, though they may still use it for all I know) and they were pretty keen on nailing down exactly what was expected on each link.
>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. Sadly that is the case with pretty much all security, but the lack of an ability to check/filter based on what security level has been negotiated means that those people who _do_ know what they are doing can't. I'm still annoyed by the general (not smtpd particularly) impossibility of having usefully functioning CRLs, which are pretty much a requirement of any PK system but have been generally ignored to date. >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)" I do not disagree >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. Fair enough - I just felt it was worth adding another point of view to the discussion. Thanks JC -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
