On Sat, March 7, 2015 12:20 pm, kim.da...@safe-mail.net wrote:
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
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.
To facilitate easier code removal, the code needs to be properly separated
first - and that is the goal of this project.
Hi Kim,
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
vulnerable.
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.
I also don't think there's the same urgency to delete the code. The
argument you give - that malware will enable it - is unfortunately an
unsolvable problem. I refer you to
https://technet.microsoft.com/en-us/library/hh278941.aspx to understand
why this is inherently so.
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
issues.
For example, NSS is enabling TLS 1.2 by default (
https://bugzilla.mozilla.org/show_bug.cgi?id=1083900 ) and disabling SSL 3
by default ( https://bugzilla.mozilla.org/show_bug.cgi?id=1140029 ), but
both of these are huge steps with *real* interop issues for applications
using NSS. We can't just ignore those and say Too bad, so sad -
including for the most obvious reason, in that applications would just
switch to TLS libraries that understood and appreciated interop concerns.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
