The Current State of SMTP STARTTLS Deployment (according to Facebook)

Discussion in 'privacy technology' started by TheWindBringeth, May 15, 2014.

Thread Status:
Not open for further replies.
  1. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,084
    https://www.facebook.com/notes/prot...-of-smtp-starttls-deployment/1453015901605223

    Does your email provider support STARTTLS?
    http://www.checktls.com/index.html
     
  2. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,833
  3. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,041
  4. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,084
    What is the terminology we should be using when talking to this situation? IMO, "strict encryption" would be used to describe contexts where strong/proper encryption is mandatory. In a STARTTLS and email sending context, that would mean:

    1) Requiring recipient MTAs to offer STARTTLS and aborting delivery attempts when it is not offered. Necessary to prevent a MITM from blocking use of STARTTLS I believe.
    2) Requiring recipient MTAs to support adequately strong ciphers.
    3) Requiring recipient MTAs to have certs that chain up to a well-known CA and validate. Necessary, in many but not all cases, to prevent a MITM from impersonating the system on the other end of the connection.

    Facebook, like other email providers, could enforce these for a set of well-know email providers they know to have fully adopted STARTTLS, strong ciphersuites, and validating certs. I'm not aware of this being a common practice, and question if any major email providers are doing it. I don't think any are requiring such things across the board. This would at present be problematic because some MTAs are not setup to support STARTTLS and others that are setup to use it are using self-signed certificates. This type of situation... where encryption is used when available but not actually required... seems more consistent with the phrase "opportunistic encryption".
     
    Last edited: Aug 19, 2014
Loading...
Thread Status:
Not open for further replies.