Re: Opportunistic TLS on mail servers

[Aarón Mizrachi <unmanarc () gmail com>]

On Jueves 19 Marzo 2009 20:53:20 usted escribió:
> I think that you may be missing the point. It is not meant to be a
> replacement for forced encryption but rather an extra layer of protection
> for mail that would otherwise be flowing in plain text. 

well, looks like WEP.

But you have a valid point for me, I agree with use "something" before 
"nothing". 

> There is no need
> for a man-in-the-middle when you are sending you mail in plain text. This
> is just another method of protecting information that would otherwise be
> flowing unprotected anyway. It provides the company yet another
> "reasonable" protection for otherwise trust-and-forget laziness.
>
> Many (if not most) companies are using email in the clear. If you can
> convince the larger companies that you send the most email to to use
> opportunistic TLS then you help to mitigate the mail that is not flowing
> through your "lets-trust-the-end-user-to-make-the-right-choice" protection
> that is no where near 100%.
>
> Not a total solution. Just another layer.

There is not a reasonable total solution because you will need to mitigate not 
only the plain-text issue, you need also to mitigate keyloggers (both hardware 
and software), trojans, rootkits, mitm attacks, human mistakes, etc.

Everything depends in what is the price of the information traveling in this 
mails. Sometimes are "Hi mr john, our meet will be at 5pm", and sometimes are 
industrial and financial secrets. 

> steve
>
> On Wed, Mar 18, 2009 at 2:55 AM, Aarón Mizrachi <unmanarc () gmail com> wrote:
> > On Miércoles 11 Marzo 2009 23:20:50 steve.dake () gmail com escribió:
> > > I am curious as to how may people have their email servers configured
> > > to perform opportunistic TLS? It seems like a cheap way to mitigate a
> > > good portion of your potential email information leakage. If you are
> > > against
> >
> > it,
> >
> > > I would like to know why. If you have used it for a while, have you had
> >
> > any
> >
> > > issues?
> >
> > Heh, opportunistic encryption are just that.. oportunistic.
> >
> > our client can be configured to use it, but... have some weakness if you
> > dont
> > force to use it... because:
> >
> > What if a man in the middle attack on a untrusted network disable or
> > downgrade
> > the encryption?
> >
> > Check for RFC 2487 to understand it:
> > > > 5. The STARTTLS Command
> > > >
> > > >  The format for the STARTTLS command is:
> > > >
> > > >   STARTTLS
> > > >
> > > >   with no parameters.
> > > >
> > > >   After the client gives the STARTTLS command, the server responds
> > > > with one of the following reply codes:
> > > >
> > > >   220 Ready to start TLS
> > > >   501 Syntax error (no parameters allowed)
> > > >   454 TLS not available due to temporary reason
> >
> > Steps:
> >
> > - You start a smtp connection
> > - a mitm attack forwarding tcp is started
> > - a mitm act as a proxy and start connection to real server
> > - you send a STARTTLS command
> > - a mitm replace your STARTTLS with nothing
> > - a mitm inject on your connection side: 454 TLS not available due to
> > temporary reason
> > - if your email-client doesnot mandatory enforce TLS, you will procced
> > without
> > TLS.
> > - Everything from this point are unencrypted redirected and logged by the
> > mitm
> > host.
> >
> > > Just interested in what everyone has to say about the topic.
> > >
> > > Article:
> > > http://securityn00dle.blogspot.com/
> >
> > Real cryptography applications involves:
> >
> > - Certificates: you have supposed to exchange the certs by a trusted
> > secured
> > way, BOTH SIDES.
> > - Certificate integrity: generation and private keys are supposed to be
> > well
> > protected. BOTH SIDES.
> > - Enforced mandatory crypto: both sides, client and server side. (SSL
> > SMTP on
> > 465 are good)
> > - Good cypher algorithm support: SSLv3 are required, check for the best
> > combination of cypher algorithms (blowfish, aes, serpent, CBC, hashing,
> > etc...)
> > and disable others weak supported algorithms (like 56-bit des)...
> >
> > To increase usability (paying it on security), you can forget the client
> > certificates.
> >
> > -----------------------------
> >
> > The server certificate and user training are mandatory... If you dummy
> > accept
> > any cert, a mitm attack could be possible and encryption are not quite
> > useful.
> >
> >
> > ------------------------------------------------------------------------
> > This list is sponsored by: InfoSec Institute
> >
> > Find the source of cybercrime! Almost every crime today involves a
> > computer or mobile device. Learn how to become a Computer Forensics
> > Examiner in InfoSec Institute's hands-on Computer Forensics Course. Up to
> > three industry recognized certs available, online computer forensics
> > training available.
> >
> > http://www.infosecinstitute.com/courses/computer_forensics_training.html
> > ------------------------------------------------------------------------


------------------------------------------------------------------------
This list is sponsored by: InfoSec Institute

Learn all of the latest penetration testing techniques in InfoSec Institute's Ethical Hacking class.
Totally hands-on course with evening Capture The Flag (CTF) exercises, Certified Ethical Hacker and Certified 
Penetration Tester exams, taught by an expert with years of real pen testing experience.

http://www.infosecinstitute.com/courses/ethical_hacking_training.html
------------------------------------------------------------------------