Separating Firefox crypto code into removable parts
Looking for comments about feasibility of breaking-up Firefox TLS/SSL-handling code into easily-removable sections.
I want to fully separate NSS code from code that handles:
1) MD5 signature handling
2) SHA1 signature handling
3) RSA key exchange
4) CBC mode
5) RC4 ciphers
7) TLSv1.0, TLSv1.1
8) SEED, IDEA, 3DES, Camellia cyphers
9) Secondary/Fallback handshake
10) Insecure TLS version feedback
and likely others.
The intention is to phase out and eventually remove support for all of the above.
Disabling those technologies in browser options is insufficient. FREAK-like attacks will exploit holes in the disabling mechanism to reenable them. Alternatively, malware, misguided forks, or clueless users will change those settings for the worse.
Removing code from the source code is the only secure way. This also helps code maintainability, review, and certifiability.
> Looking for comments about feasibility of breaking-up Firefox
> TLS/SSL-handling code into easily-removable sections.
> I want to fully separate NSS code from code that handles:
> 1) MD5 signature handling
> 2) SHA1 signature handling
> 3) RSA key exchange
> 4) CBC mode
> 5) RC4 ciphers
> 6) SSLv3
> 7) TLSv1.0, TLSv1.1
> 8) SEED, IDEA, 3DES, Camellia cyphers
> 9) Secondary/Fallback handshake
> 10) Insecure TLS version feedback
> and likely others.
> The intention is to phase out and eventually remove support for all of the
> Disabling those technologies in browser options is insufficient.
> FREAK-like attacks will exploit holes in the disabling mechanism to
> reenable them. Alternatively, malware, misguided forks, or clueless users
> will change those settings for the worse.
> Removing code from the source code is the only secure way. This also helps
> code maintainability, review, and certifiability.
> To facilitate easier code removal, the code needs to be properly separated
> first - and that is the goal of this project.
Unfortunately, I believe you start from a flawed premise, and thus the
rest sort of falls apart.
That is, while removing the code may help long term, separating the code
out does not help maintainability or readability - and in fact, can
greatly hinder them.
Plenty of implementations that have striven to fully separate out their
TLS 1.0, TLS 1.1, and TLS 1.2 stacks have thus fallen victim to bugs. For
example, I can think of one prominent implementor that failed to fix BEAST
because they only fixed one of their implementations, and left the others
TLS version fallback, for example, is not implemented in NSS.
MD5/SHA1 signature handling is already separated, but you still need it in
some contexts, but not others. Even more so CBC - whose use in NSS extends
far beyond SSL and has many independent applications that would need
independent timelines for deprecation.
In short, I think the plan of separating out that code to be
well-intentioned, but misguided. It's also something that, as a mature
software project with many consumers, will require care and caution rather
than wholesale deleting. And since I've been accused in the past
(amusingly so) of trying to keep backdoors in, no, this is about the
tension of a responsible and open software development practice and
balancing the needs for security.
The other arguments are equally problematic. Misguided forks (there have
been none yet) and clueless users (whom, if we accept as a threat model,
can do anything and everything hostile to security, including running
malware) are similarly specious.
Rather than focus on removing the code, perhaps it's better to think about
how best to phase things out - with attention being paid to the attendant