STARTTLS support is only opportunistic, can't be required
Closed this issue · 1 comments
#10 implemented opportunistic STARTTLS support. It checks whether the server reports STARTTLS as an option during the initial EHLO over an unencrypted connection. However, an active attacker / MITM attack can opt to not report STARTTLS and bypass encryption entirely.
In the Gaia email app and in our monkeypatches (the removal of which is tracked at https://bugzil.la/1060558) we pass in to our account constructors either { crypto: 'ssl' } to convey initial-TLS or { crypto: 'starttls' } to convey mandatory STARTTLS upgrade. I think this is a sensible strategy, although it might be a good idea to avoid reusing 'useSecureTransport' for this since that implies TCPSocket semantics which wouldn't support 'starttls'. Note that I don't really have a strong opinion here.
When implementing required STARTTLS it would be good to ensure that an explicit error code or family of error codes conveys that establishing a connection failed for security reasons. (Failure to indicate support of STARTTLS, failure to honor STARTTLS, certificate problems when performing STARTTLS, etc.) See #9 for some brief discussion/references of how the Gaia email app currently deals with errors.
fixed with #14
will publish to npm on monday