1

If I'm feeling paranoid about the CCDP (UK) - requiring ISPs to intercept communications across the internet - then what would be the most secure approach to a webmail system?

Obviously, there's some legal/political stuff (can I rely on the people running it, can I rely on the legal jurisdiction that it's located in, etc) but on a technical level, what would be a strong approach to running a webmail service that can't be cracked by an MITM attack run by my users' ISPs?

It strikes me that there are several things that will make a difference compared to a typical commercial service like Gmail:

  1. HTTPS, using TLS v.1.2 with well-selected cyphersuite choices (I'm not sure which cyphersuites would be right). Now that OpenSSL 1.0.1 is out, requiring TLS 1.2 is possible, though you'd lock out NSS-dependent browsers (Firefox and Chrome - which means Opera only on non-Windows OS; Safari/Win supports TLS 1.2 but not Safari/Mac).
  2. No JavaScript (and therefore no AJAX), with possibly a tiny piece of JavaScript that prevents access to the site if JS is turned on at the client.
  3. Deliver all content from a single domain name / IP address (no "static" domain, no ads, no Google Analytics, etc).

I'm not intending to actually implement such a service (I'm not in a suitable legal jurisdiction, for a start) but I'm sure there are other things that could be done.

Any suggestions, thoughts?

700 Software
  • 13,807
  • 3
  • 52
  • 82
Richard Gadsden
  • 501
  • 1
  • 4
  • 11
  • 2
    To start with, I don't think that disabling JavaScript will provide much value, unless you had an XSS vulnerability. – 700 Software Apr 07 '12 at 22:42
  • It would give a fair bit of reassurance to the customer that I don't have an XSS vulnerability – Richard Gadsden Apr 08 '12 at 00:22
  • Should mention that the argument for point 3 is that it means that the user can turn on "mixed content" warnings, third-party blocking and so on, plus it means that there's only one SSL certificate to check (MITM can be done by substituting SSL certificates) – Richard Gadsden Apr 08 '12 at 00:24

2 Answers2

2

The primary things you can do are:

  • Use SSL sitewide. Disable HTTP (non-SSL) access, or redirect users to the SSL version of the web site.

  • Use HSTS to declare to clients that they should only connect via SSL.

  • Make sure that all cookies have the secure flag set. This will ensure that your user's browsers will only send those cookies back over SSL-protected connections and never disclose them over any non-SSL (HTTP) link.

  • Add your site to Chrome's hard-coded list of HSTS sites (the HSTS preloaded list).

  • Add your site's public key to Chrome's public-key pinning list, if they'll let you.

  • Check that your SSL server is properly configured, using standard SSL configuration checkers: e.g., SSL Labs.

  • Make sure that your certificate is valid.

  • Consider buying an Extended Validation (EV) certificate. You could also mention somewhere in the support section of your site that you encourage users to check for the green glow in their address bar every time they visit your site. (Probably this won't be highly effective, but it might help a little bit.)

  • Consider providing a link to Chrome and HTTPS Everywhere on your web site somewhere.

  • Configure your web server to defend against the BEAST attack. Enabling TLS 1.2 is a good idea, but you may also want to choose carefully the preference order of algorithms, to help protect users whose browsers don't yet support TLS 1.2 (which will be essentially all of them right now).

  • If you provide access via IMAP, make sure you only support IMAPS (the SSL-enabled version), not the cleartext IMAP.

  • Enable STARTTLS on your SMTP server.

  • Avoid use of third-party Javascript widgets (e.g., libraries, widgets, like buttons, etc.). Don't load external content over http.

I would not try to avoid use of Javascript. I especially would not try to block access to users who have Javascript enabled. That is a usability disaster, for little or no security gain.

See also Guidance for implementors of HTTPS-only sites (Server side).

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
0

Since I know all of the DLP (Data Loss Prevention) vendors do MITM on SSL connections in conjunction with the Proxy vendors, out of the box there is really nothing you can do. The weakness is in the protocol and not the application. I would recommend using a two-factor solution using something like Yubikeys, but I'm not sure if that would prevent the hijacking of the sessions. If the certificates could be built on the fly that would use the OTP that the Yubkikey provides that might do the trick. SSL/TLS needs to be rewritten to account for MITM.

http://www.yubico.com/yubikey

Justin Andrusk
  • 305
  • 1
  • 6
  • 1
    Don't the DLP vendors do MITM on SSL by forcing the browsers to accept a root CA from the proxy, and then issuing a certificate on-the-fly for the SSL website to do MITM (so there are two SSL sessions - one from browser to proxy, using the proxy-issued certificate, and the other from proxy to destination server, using the real certificate)? As long as the browser can't be forced to accept a root CA (ie, as long as it's under the control of the user), that problem shouldn't apply. – Richard Gadsden Apr 08 '12 at 00:20
  • @RichardGadsden that was my understanding too. Also, it's not limited to DLP products; many proxy/web security products have this functionality as well. – lew Apr 08 '12 at 01:01
  • @RichardGadsden, in some environments (e.g., business/enterprise settings), the system administrators install a root CA on your browser without your consent (precisely to enable DLP devices to mount a MITM attack on you). This may not be applicable for consumer devices, but for people who are checking their email from work, it could be a problem. – D.W. Apr 10 '12 at 20:21
  • @D.W. That can't be done without your consent on your own computer - but it clearly can be done for a work computer that belongs to your work. Interesting point about people checking email from work. – Richard Gadsden Apr 11 '12 at 13:35