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

>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.



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

Reply via email to