Separating Firefox crypto code into removable parts

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Separating Firefox crypto code into removable parts

kim.davis
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.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Separating Firefox crypto code into removable parts

Ryan Sleevi
On Sat, March 7, 2015 12:20 pm, [hidden email] 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto