4 ms·

Two notes: (1) While Google uses forward-security on their HTTPS connections, I've not yet seen evidence either way as to whether the SMTP-TLS connections (rel

by gojomo 13y ago

Two notes: (1) While Google uses forward-security on their HTTPS connections, I've not yet seen evidence either way as to whether the SMTP-TLS connections (relaying email to other domains) use forward-security. (The report at checktls.com mentions only the cipher "RC4-SHA", not the key-exchange mechanism.) (2) If one side of the connection chooses to retain its session keys, or chooses session keys in a poor/predictable manner, or leaks information about session keys via a side-channel (either by mistake or intent), then the forward-security could be destroyed, and in a very subtle/undetectable way. (This could be a cheap and sly way to grant visibility to a third-party: adopt forward-security outwardly, but ensure your session keys only look random to people who don't know the bug/secret-seed-shared-with-the-third-party.)

e12e 13y ago
Thanks for asking this -- apparently there is no really easy tool for this (I was thinking openssl s_client could do this automagically -- apparently not) -- however, see: http://superuser.com/questions/109213/is-there-a-tool-that-can-test-what-ssl-tls-cipher-suites-a-particular-website-of http://superuser.com/questions/109213/is-there-a-tool-that-c... And now I realized I hadn't tuned the SSL ciphers on one of my servers to not accept (among other thing NULL ciphers... at least if that bash-script works -- I'll have to double check).
- jervisfm 13y ago
  You should check out https://ssllabs.com https://ssllabs.com. They accept a URL and do SSL checks to determine if your server is not configured in the most secure manner possible. It is already interesting to run the check against online banking sites to see first hand how seriously they take security in practice. I was surprised to see that some banks score pretty poorly in this regard.
  - gojomo 13y ago
    I don't find an option at ssllabs.com to check SMTP (the topic of this thread). Am I overlooking it?
    - e12e 13y ago
      No, you're not. It would be nice if they had one, though.
- e12e 13y ago
  I'm not sure I'm brave enough to force forward secrecy in my Exim config just yet -- I can't find an option to log handshakes (unless it is logged as part of the message logs -- which can be kept) -- but I suppose refused messages would show up in the reject log. Still, I'm not sure if I'm even ready to force SSL at all... for incomming SMTP. Sounds like a good way to break your email infrastructure (and reduce spam ;-). Essentially mail transport is pretty much unencrypted -- I see SSL/TLS having potential to help fight spam by forcing some form of authentication (via DNS sec, CAs etc) -- but not really a useful tool for securing email from snooping -- for that I would advocate S/MIME and/or GnuPG (Gnu Privacy Guard).
X-Istence 13y ago
Every so often I get a mail server from Google that uses DHE outgoing, but most of the time it is RC4-SHA at 128 bits/128 bits. There are plenty of other mail servers sending me mail though that are sending it over DHE-RSA-AES256-SHA. I may go tighten up the ciphers I accept. Maybe if only given the option for PFS ciphers Google's mail servers will use them.
Amadou 13y ago
How much SSL traffic is offloaded to dedicated hardware on the server side nowadays? How many different companies are there in that space? How many of them have secret agreements with the NSA (or their respective state intelligence agencies) to retain session keys and dump them out when they receive the right kind of query? The actual owner of the SSL offload hardware would have a hell of time even detecting that their keys were being handed out that way - picking out a once-a-day SSL connection that the offload hardware talks to directly versus one that it passes through in the clear to the systems behind it is going to be exceptionally difficult.
- thrownaway2424 13y ago
  I think the amount of SSL hardware in the field is closer to zero. Nobody with any clue uses that stuff because it's power hungry, the APIs are awful, the implementations can't be verified, and any such asic will look slow in a year whereas cloud server lifetime is five years. AESNI killed those guys a long time ago. The only users of them are embedded platforms without the host CPU power to do crypto.
  - rdl 13y ago
    It still gets used sometimes in hardware load balancers (I guess that is "embedded platforms"). Some of those turn out to actually be more like software, though.
  - zurn 13y ago
    Really? I thought a lot (most?) of the big boys used load balancers that include SSL termination along with DoS protection and the load balancing itself. BTW anyone know how AWS load balancing works in this regard?
    - rdl 13y ago
      As far as I can tell, ELBs are just commodity EC2 nodes, which are actually pretty shitty because they're EBS backed; you can build a better ELB yourself using an S3 backed EC2 node. Some of the OpenStack people were using hardware load balancers (F5; I think maybe HP OpenCloud?) as an option.
inopinatus 13y ago
Quick log check. For the last month at least, all SMTP-TLS that my servers received from Google was using ECDHE-RSA-RC4-SHA. Same for Yahoo mail. Hotmail, by contrast, never uses it, nor is STARTTLS offered by their MXes.

by gojomo 13y ago

e12e 13y ago

Thanks for asking this -- apparently there is no really easy tool for this (I was thinking openssl s_client could do this automagically -- apparently not) -- however, see: http://superuser.com/questions/109213/is-there-a-tool-that-can-test-what-ssl-tls-cipher-suites-a-particular-website-of http://superuser.com/questions/109213/is-there-a-tool-that-c... And now I realized I hadn't tuned the SSL ciphers on one of my servers to not accept (among other thing NULL ciphers... at least if that bash-script works -- I'll have to double check).

jervisfm 13y ago
You should check out https://ssllabs.com https://ssllabs.com. They accept a URL and do SSL checks to determine if your server is not configured in the most secure manner possible. It is already interesting to run the check against online banking sites to see first hand how seriously they take security in practice. I was surprised to see that some banks score pretty poorly in this regard.
- gojomo 13y ago
  I don't find an option at ssllabs.com to check SMTP (the topic of this thread). Am I overlooking it?
  - e12e 13y ago
    No, you're not. It would be nice if they had one, though.
e12e 13y ago
I'm not sure I'm brave enough to force forward secrecy in my Exim config just yet -- I can't find an option to log handshakes (unless it is logged as part of the message logs -- which can be kept) -- but I suppose refused messages would show up in the reject log. Still, I'm not sure if I'm even ready to force SSL at all... for incomming SMTP. Sounds like a good way to break your email infrastructure (and reduce spam ;-). Essentially mail transport is pretty much unencrypted -- I see SSL/TLS having potential to help fight spam by forcing some form of authentication (via DNS sec, CAs etc) -- but not really a useful tool for securing email from snooping -- for that I would advocate S/MIME and/or GnuPG (Gnu Privacy Guard).

X-Istence 13y ago

Every so often I get a mail server from Google that uses DHE outgoing, but most of the time it is RC4-SHA at 128 bits/128 bits. There are plenty of other mail servers sending me mail though that are sending it over DHE-RSA-AES256-SHA. I may go tighten up the ciphers I accept. Maybe if only given the option for PFS ciphers Google's mail servers will use them.

Amadou 13y ago

How much SSL traffic is offloaded to dedicated hardware on the server side nowadays? How many different companies are there in that space? How many of them have secret agreements with the NSA (or their respective state intelligence agencies) to retain session keys and dump them out when they receive the right kind of query? The actual owner of the SSL offload hardware would have a hell of time even detecting that their keys were being handed out that way - picking out a once-a-day SSL connection that the offload hardware talks to directly versus one that it passes through in the clear to the systems behind it is going to be exceptionally difficult.

thrownaway2424 13y ago
I think the amount of SSL hardware in the field is closer to zero. Nobody with any clue uses that stuff because it's power hungry, the APIs are awful, the implementations can't be verified, and any such asic will look slow in a year whereas cloud server lifetime is five years. AESNI killed those guys a long time ago. The only users of them are embedded platforms without the host CPU power to do crypto.
- rdl 13y ago
  It still gets used sometimes in hardware load balancers (I guess that is "embedded platforms"). Some of those turn out to actually be more like software, though.
- zurn 13y ago
  Really? I thought a lot (most?) of the big boys used load balancers that include SSL termination along with DoS protection and the load balancing itself. BTW anyone know how AWS load balancing works in this regard?
  - rdl 13y ago
    As far as I can tell, ELBs are just commodity EC2 nodes, which are actually pretty shitty because they're EBS backed; you can build a better ELB yourself using an S3 backed EC2 node. Some of the OpenStack people were using hardware load balancers (F5; I think maybe HP OpenCloud?) as an option.

inopinatus 13y ago

Quick log check. For the last month at least, all SMTP-TLS that my servers received from Google was using ECDHE-RSA-RC4-SHA. Same for Yahoo mail. Hotmail, by contrast, never uses it, nor is STARTTLS offered by their MXes.