1
$\begingroup$

I have an embedded system product that emails out event notifications periodically. I have implemented a non secured email version, but want to use SSL/TLS, if possible. Can I only use 1 cipher suite for space considerations? Or, do I have to support many types? I'm trying to keep it simple, but not sure if there will be issues with just one or a couple. Any input on how others would handle a simple one-way email feature using SSL/TLS?

$\endgroup$
  • $\begingroup$ Would your device act as the client in these communications or as the server (ie be the connectee rather than the connector)? Are you worried about code size or data transmission overhead? $\endgroup$ – SEJPM Apr 5 '17 at 9:17
  • $\begingroup$ It would solely used as a client to connect to an unknown server to send out an email. Code size is a major issue on an embedded system. Not sure how many cipher suites to support. $\endgroup$ – Sutton Mehaffey Apr 5 '17 at 13:35
  • $\begingroup$ In that case I'd suggest you keep a close eye on the development of BearSSL which is highly optimized on code-size (but not yet production-ready). $\endgroup$ – SEJPM Apr 5 '17 at 13:37
2
$\begingroup$

You can support as many or as few as you like - take a look at RC 5247 for TLS 1.2. If you are on an embedded system w/o any hardware crypto, you may want to skip the RSA algs that take a long time in favor of the ECDH. In any case, look for an embedded crypto library that available for your toolchain and cpu vs writing it yourself. It'll save time as well implementation flaws.

You might try initiating a TLS session with one of these email hosts and see what comes back for the algorithms they support - I suspect it's pretty extensive. Then you could be sure that the ones you pick will work.

Wireshark is your friend for this.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks. I've looked into embedded libraries, but most vendors want to charge for all kinds of other stuff that I don't need. Which also adds unwanted code to our code space. Our product is going to be connecting up to other people's servers and we have no idea what kind of server or what ciphers those servers will support. So, I was trying to determine what I was up against as far which cipher suites to support. If servers can support any one they want, then I'm guessing that if our product doesn't support all of them, then there is the possibility that a particular server won't connect. $\endgroup$ – Sutton Mehaffey Apr 5 '17 at 13:32
  • $\begingroup$ Of course, we could always drop back to our unsecured email option. $\endgroup$ – Sutton Mehaffey Apr 5 '17 at 13:32
1
$\begingroup$

For each server that you product will communicate with, your product needs to have a ciphersuite in common with that server. If you have some control over the servers, then it's perfectly fine to pick one ciphersuite and require that the servers must support this ciphersuite. If possible, however, it would be better to support at least two different ciphersuites; that way, if one of them turns out to be broken, the other one may be a suitable fallback. If your product needs to interact with other people's servers,

RFC 7925, which is intended to apply to low-end devices, recommends the use of ECDHE (specifically TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8) with the curve secp256r1. Mozilla has somewhat different recommendations, with a preference for GCM-based ciphersuites (see Security of authenticated encryption modes GCM & CCM and How to choose between AES-CCM and AES-GCM for storage volume encryption regarding CCM vs GCM; it isn't a decisive factor in security but GCM might offer better performance). Servers that seek browser compatibility with a restricted set of ciphersuites might be more inclined to support only one or a few of these.

Note that using TLS for email isn't a panacea, because it only secures the connection to the first hop. The email is only protected if all the hops on the email's path use TLS and all the intermediate servers are trusted, which in general is difficult to ensure. Unless your product operates in a closed environment where the path of an email is guaranteed to go through trusted servers only, to achieve confidentiality and authenticity of the email, you need some form of end-to-end protection. This is typically done with either PGP or S/MIME. TLS on top of that does have some advantages (confidentiality of the headers, which in particular provides privacy regarding the sender and the recipient up to what is revealed by the email's path; also, protection against replay), but all these advantages only hold only inside the domain where all email servers are trusted, they're lost as soon as the email hits an untrusted intermediate server, as is the confidentiality and authenticity of the body.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks. Our products will connect to other people's servers and we have no idea what kind of server or what ciphers those servers will support. Since this is only an outbound email feature, I am trying to determine how simple or complex the cipher suites need to be. $\endgroup$ – Sutton Mehaffey Apr 5 '17 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.