Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Julien Vehent]

On 2013-08-26 17:24, Brian Smith wrote:

Conversely, it isn't clear that AES-256 offers any significant security
advantage over AES-128, though it is clearly slower, even on my
AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well
so that it might just be good enough in general.


I ran some measurements on various CPUs, including slow ones, both with and 
without AES-NI. The full table is at the end of this email.
It seems that AES-256 is always 25% to 30% slower than AES-128, regardless 
of AES-NI, or the CPU family.
With one exception: AESNI on Intel i7. On this CPU, and for block sizes of 
16 64, 256 and 1024 bytes, AES-256 is ~80% slower than AES-128. For a block 
size of 8192 bytes, AES-256 is 28.7% slower.


The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which 
is probably fast enough for any browser


If performance was the only reason to prefer AES-128, I would disagree with 
the proposal. But your other arguments regarding AES-256 not provided 
additional security, are convincing.



Secondly, as I already
pointed out in my proposal, some research has shown that AES-256 doesn't
seem to offer much more security than what we understand AES-128 to offer.
See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and
https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time
implementations are used, AES-256 seems to offer more opportunity for
timing attacks than AES-128 does, due to more rounds and larger inputs.



This paper: eprint.iacr.org/2007/318.pdf
  On the complexity of side-channel attacks on AES-256
- methodology and quantitative results on cache attacks -

Seems to suggest something similar:

In this paper, we addressed side-channel attacks on AES-256: we 
demonstrated with
practical results that the complexity (i.e. resistance) increase with 
the number of key
bits is virtually non-existent. In particular, for the cache based 
attacks, an attack on
AES-256 is only 6 to 7 times as hard as an attack on AES-128 both in the 
required
computing power as in the required number of observations. We used the 
cache side-
channel as an example side-channel, but the methodology presented in 
this work can

be applied to leverage any other channel and attack AES-256.

However, it refers to software implementations of AES. Do we know if this 
result still applies for AESNI?


---
Julien Vehent
http://jve.linuxwall.info



--- Speed measurements of AES on several families of CPUs ---

   | type|  16_bytes  |  64_bytes  |  256_bytes | 1024_bytes | 
8192_bytes | CPU

---+-++++++--
AESNI  | aes-128-cbc | 669744.67k | 720971.18k | 754488.83k | 758975.49k | 
754668.89k |  Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
AESNI  | aes-192-cbc | 580606.16k | 618596.46k | 630121.39k | 630994.60k | 
633320.79k |  Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
AESNI  | aes-256-cbc | 507602.55k | 534540.84k | 544787.63k | 540530.35k | 
543763.11k |  Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
regular| aes-128-cbc | 138017.61k | 150701.59k | 154806.19k | 153791.49k | 
156374.36k |  Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
regular| aes-192-cbc | 117436.95k | 126625.64k | 128216.15k | 129753.77k | 
130247.34k |  Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz
regular| aes-256-cbc | 102283.73k | 109657.30k | 111773.61k | 112319.15k | 
112596.31k |  Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz

---+-++++++--
AESNI  | aes-128-cbc | 574168.83k | 612081.11k | 620871.25k | 626095.10k | 
623520.43k |  Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
AESNI  | aes-192-cbc | 122382.52k | 130687.70k | 136055.47k | 151552.68k | 
395365.03k |  Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
AESNI  | aes-256-cbc | 111402.54k | 114350.49k | 125160.36k | 174099.46k | 
443987.29k |  Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
regular| aes-128-cbc | 2.35k  | 33039.47k  | 86861.99k  | 127958.36k | 
128316.76k |  Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
regular| aes-192-cbc | 24563.96k  | 26540.95k  | 32132.95k  | 36337.66k  | 
71385.09k  |  Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
regular| aes-256-cbc | 21766.37k  | 29087.62k  | 26345.47k  | 25728.00k  | 
27989.33k  |  Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz

---+-++++++--
AESNI  | aes-128-cbc | 27391.57k  | 42004.99k  | 49039.45k  | 51120.81k  | 
51716.10k  |  Intel(R) Atom(TM) CPU D510   @ 1.66GHz (NO AESNI SUPPORT)
AESNI  | aes-192-cbc | 24954.17k  | 36496.21k  | 41651.46k  | 43204.27k  | 
43677.01k  |  Intel(R) Atom(TM) CPU D510   @ 1.66GHz (NO AESNI SUPPORT)
AESNI  | aes-256-cbc | 22912.58k  | 31863.87k  | 35590.14k  | 36657.49k  | 
36975.96k  |  Intel(R

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Julien Vehent]

On 2013-09-12 22:01, Julien Pierre wrote:

Julien,

On 9/12/2013 07:06, Julien Vehent wrote:
If performance was the only reason to prefer AES-128, I would disagree 
with the proposal. But your other arguments regarding AES-256 not provided 
additional security, are convincing.


The performance is still an issue for servers. More servers are needed if
more CPU-intensive crypto algorithms are used.


aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES bandwidth 
on a single core.
On a decent 8 core load balancer, dedicate 4 to TLS, and you get 17.40Gbps 
of AES bandwidth.
I don't this AES is close to being the limiting factor here. Processing HTTP 
is probably 20 times more expensive than that.


Just reinforcing the point that performance is not, in my opinion, an issue. 
The quality of AES-256 is much more relevant here.



---
Julien Vehent
http://jve.linuxwall.info


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Julien Vehent]

On 2013-09-12 23:11, Stefan Arentz wrote:

How about mobile?



Mobile is not an issue.

Updated table that contains speed test on Android with an ARMv7 (Galaxy S3): 
http://jve.linuxwall.info/ressources/taf/aesmeasurements.txt
You can see that the ARM7 does AES-{128,256} in the 50 to 70MB/s range. I 
was actually surprised by the results, I had no idea ARMs cpus could compute 
AES that fast, and all in software since there's no AES-NI in ARM (yet...).


What about the initial key exchange that SSL/TLS does? I thought that was 
the

biggest CPU killer?


Absolutely. And that's still true. I'm only discussing AES-128 vs AES-256 
here.



- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: TLS 1.2 Issue with openldap 2.4.36 built on NSS 3.15.3

[Julien Vehent]

On 2013-11-26 13:37, Kurt Roeckx wrote:

On Tue, Nov 26, 2013 at 01:14:50PM +, Sameer Stephen wrote:

Hi,

We have an application which uses pam_ldap.so module to connect to LDAP 
server. Our application( i.e. client ) uses openldap(2.4.36) which  is 
built against mozilla NSS library(3.15.3) and as per NSS mozilla official 
website, it supports TLSv1.2 protocol/ciphers. Our application run on RHEL 
6 and we have configured pam_ldap.conf with following parameters:


===
host XXX
base dc=, dc=
ssl on
tls_ciphers TLSv1.2+HIGH:!AESGCM:!aNULL:!eNULL
===


That looks like an openssl string to me.


I build a correspondence table between IANA, OpenSSL, GnuTLS and NSS a 
couple weeks ago, it might help you convert this tls_ciphers into something 
NSS understands.


https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table

---
Julien Vehent
OpSec@Mozilla
http://jve.linuxwall.info


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2013-12-14 19:47, Kosuke Kaizuka wrote:

Camellia is widely reviewed and chosen as a recommended cipher by
several independent committees.
If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also
dropped.



There is another reason to drop CAMELLIA: AES with AES-NI is 8 times
faster. AES-NI is supported by the majority of server CPUs right now.

Camellia is still fast in software, my laptop computes between 90 and
160 MB/s with openssl and an intel cpu. But if we want to provide the
fastest response time to users, it's important to consider the server
cost on the client side.


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2013-12-15 11:13, Kurt Roeckx wrote:

On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote:

On 2013-12-14 19:47, Kosuke Kaizuka wrote:
Camellia is widely reviewed and chosen as a recommended cipher by
several independent committees.
If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also
dropped.


There is another reason to drop CAMELLIA: AES with AES-NI is 8 times
faster. AES-NI is supported by the majority of server CPUs right now.

Camellia is still fast in software, my laptop computes between 90 and
160 MB/s with openssl and an intel cpu. But if we want to provide the
fastest response time to users, it's important to consider the server
cost on the client side.


It's not because it's enabled that you have to use it.  The
priority of Camellia is now always below AES.  If the server
supports AES it should pick it.


Right. And by drop I really meant reduce preference of.

For the same reason, the server ciphersuite that we recommend at
https://wiki.mozilla.org/Security/Server_Side_TLS
does not drop Camellia, but lists it at the bottom of the ciphersuite.
It's a safe choice, but not one that we recommend.


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2013-12-29 18:30, Kurt Roeckx wrote:

On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote:

For the same reason, the server ciphersuite that we recommend at
https://wiki.mozilla.org/Security/Server_Side_TLS
does not drop Camellia, but lists it at the bottom of the ciphersuite.
It's a safe choice, but not one that we recommend.


You might also want to read:
https://bettercrypto.org/


[cc-ing the cert.at mailing list that published this guide]

Thanks for the link! I wasn't aware of this guide.

Overall, I think this guide is great! The configuration examples are very 
useful.
It's also good to have multiple TLS guides with different audiences, so I'm 
definitely

glad to see more people take on the issue.

I need to do a thorough read of the entire thing. I am a bit puzzled by some 
of the
choices made around their ciphersuite B (the most realistic and practical 
one). Most
of the ciphersuite construction sections are still empty, so it's hard to 
understand
what exactly is intended. I did notice a few things that I, personally, find 
arguable:


Why prefer DHE to ECDHE, when the former is 3 times slower than the later?
There is a bit of a justification in 3.5:
Since there is much discussion on the security of ECC, flawed settings 
might very

 well compromise the security of the entire system.
I wish there was references to these discussions. My understanding of the 
state of

the art of ECC is that P-256 is considered at least as secure as DH and RSA.

They recommend AES-128 in 3.4. Keylengths, but publish a ciphersuite that 
prefers
AES-256 (see below). This is probably just an oversight, the guide is still 
in Draft.


The guide is not backward compatible with all clients. We, at Mozilla, must 
maintain
backward compatibility with even the oldest, most broken, clients on the 
internet, and
this shapes our guidelines. For example, the ciphersuite B doesn't contain 
3DES or RC4,
and is therefore unusable on *a lot* of PC that still run Windows XP. I wish 
we could
just remove these two ciphers, but it's not a realistic goal in the near 
future.


Same goes for the recommendation to use DH parameters  1024 bits. We tried 
using a 2048
bits parameter a few months back. We first noticed a big spike in CPU usage, 
caused by
the largest exponentiation, but that was still acceptable. What forced the 
rollback is
the long list of java 6 clients that broke, because they don't accept DH 
keys  1024 bits.
Until all of these clients get fixed, DH params will be limited to 1024 
bits.


I *think* they want to prefer CAMELLIA to AES, judging by the published 
ciphersuite.
But the construction must be wrong because it returns AES first. If the 
intent is to

prefer Camellia, then I am most interesting in the rationale.

ECDSA is explicitely discarded. It doesn't hurt to have it enabled, and 
makes the
ciphersuite portable to systems that prefer ECDSA certicates (granted, it's 
not that many...).


$ openssl ciphers -v 
'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'|column 
-t
DHE-RSA-AES256-GCM-SHA384TLSv1.2  Kx=DHAu=RSA  Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-SHA256TLSv1.2  Kx=DHAu=RSA  Enc=AES(256)   
Mac=SHA256
ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=RSA  Enc=AESGCM(256)
Mac=AEAD
ECDHE-RSA-AES256-SHA384  TLSv1.2  Kx=ECDH  Au=RSA  Enc=AES(256)   
Mac=SHA384
DHE-RSA-AES128-GCM-SHA256TLSv1.2  Kx=DHAu=RSA  Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-SHA256TLSv1.2  Kx=DHAu=RSA  Enc=AES(128)   
Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=RSA  Enc=AESGCM(128)
Mac=AEAD
ECDHE-RSA-AES128-SHA256  TLSv1.2  Kx=ECDH  Au=RSA  Enc=AES(128)   
Mac=SHA256
DHE-RSA-CAMELLIA256-SHA  SSLv3Kx=DHAu=RSA  Enc=Camellia(256)  
Mac=SHA1
DHE-RSA-AES256-SHA   SSLv3Kx=DHAu=RSA  Enc=AES(256)   
Mac=SHA1
ECDHE-RSA-AES256-SHA SSLv3Kx=ECDH  Au=RSA  Enc=AES(256)   
Mac=SHA1
DHE-RSA-CAMELLIA128-SHA  SSLv3Kx=DHAu=RSA  Enc=Camellia(128)  
Mac=SHA1
DHE-RSA-AES128-SHA   SSLv3Kx=DHAu=RSA  Enc=AES(128)   
Mac=SHA1
ECDHE-RSA-AES128-SHA SSLv3Kx=ECDH  Au=RSA  Enc=AES(128)   
Mac=SHA1
CAMELLIA256-SHA  SSLv3Kx=RSA   Au=RSA  Enc=Camellia(256)  
Mac=SHA1
AES256-SHA   SSLv3Kx=RSA   Au=RSA  Enc=AES(256)   
Mac=SHA1
CAMELLIA128-SHA  SSLv3Kx=RSA   Au=RSA  Enc=Camellia(128)  
Mac=SHA1
AES128-SHA   SSLv3Kx=RSA   Au=RSA  Enc=AES(128)   
Mac=SHA1


--
Julien Vehent
OpSec @ Mozilla
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

Hi Aaron,

On 2014-01-02 16:10, Aaron Zauner wrote:

Hi Kurt,

On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote:


On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
I *think* they want to prefer CAMELLIA to AES, judging by the 
published ciphersuite.
But the construction must be wrong because it returns AES first. 
If the intent is to

prefer Camellia, then I am most interesting in the rationale.

Thanks for reporting this!

Yes. The intent was to prefer Camellia where possible. First off we 
wanted to have more diversity. Second not everybody
is running a sandybridge (or newer) processor. Camellia has better 
performance for non-intel processors with about the

same security.


I would argue that our documents target server configurations, where 
AES-NI is now a standard.




What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec.
Team by the way?


There are 5 security teams at Mozilla, so Mozilla Sec Team is a very 
large group.
I think we all want a new stream cipher in TLS to replace RC4. But 
that's going
to take years, and won't help the millions of people who don't replace 
their software

that often.

From an Operations Security point of view, the question is: how do we 
provide the
best security possible, with the cards we currently have in our hands, 
and without
discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the 
short term.


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

Hi Aaron,

Two things I'd like to mention before I reply:

1. I think it's great to have two guides with divergent points of view. 
I'm mostly
   interested in discussing design choices, because these discussions 
are useful.
   I'm not interested in convincing the ACH group that one 
recommendation is better

   than the other, since it completely depends on the context.

2. My experience as a web hosting engineer, and sysadmin, has convinced 
me that
   building security recommendations on what academia thinks alone is 
very dangerous.
   Security doesn't live in a bubble. It depends on people and systems. 
It must

   protect an activity, but never ever block it entirely.

That being said, I put my comments below.

On 2014-01-02 15:33, Aaron Zauner wrote:
On 02 Jan 2014, at 18:09, Julien Vehent jul...@linuxwall.info 
wrote:
Why prefer DHE to ECDHE, when the former is 3 times slower than the 
later?

There is a bit of a justification in 3.5:
   Since there is much discussion on the security of ECC, flawed 
settings might very

well compromise the security of the entire system.
I wish there was references to these discussions. My understanding 
of the state of
the art of ECC is that P-256 is considered at least as secure as DH 
and RSA.

Well, no. Bernstein and Lange have been auditing NIST/SECG and other
standardized curves that are
currently implemented in crypto libraries over the last years. They
may be considered secure against
the ECDLP (some) but other issues remain that caused us to prefer DHe
over ECDHe.
We’re aware of the performance implications - the paper in general
tries to cope with best performance
and backwards compatability, but not at the cost of security. I’m
aware that this philosophy might differ
to that of the Mozilla Security Team. Recent publications have
prompted some change in mindset though
and one cannot recommend a security guide that takes all factors into
consideration at the potential cost
of (side channel) attacks or downgrade attacks.

Please take the time to read up on:
- http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
- http://safecurves.cr.yp.to/
-

http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters

(There’s also interesting research to Koblitz curves in the reply by
thomas pornin)



I will bail here. My understanding of the mathematics of ECC isn't 
sufficient to make
a strong decisions. Others at Mozilla, Google and major organizations 
have decided

to implement ECC, and we trust their decision.

From my end, the decision to prefer ECC to DHE in Mozilla's guidelines 
is performance oriented.




They recommend AES-128 in 3.4. Keylengths, but publish a 
ciphersuite that prefers
AES-256 (see below). This is probably just an oversight, the guide 
is still in Draft”.

Our viewpoint was that if possible, take a stronger cipher. We’re
aware that people might want
to change this in their configuration if performance is paramount. We
probably should discuss this again.



Aside from performance, timing attacks are apparently easier in 
AES-256.

https://groups.google.com/forum/#!msg/mozilla.dev.tech.crypto/36na1B2brGU/xUMMPMgkmEMJ

The guide is not backward compatible with all clients. We, at 
Mozilla, must maintain
backward compatibility with even the oldest, most broken, clients on 
the internet, and
this shapes our guidelines. For example, the ciphersuite B doesn't 
contain 3DES or RC4,
and is therefore unusable on *a lot* of PC that still run Windows 
XP. I wish we could
just remove these two ciphers, but it's not a realistic goal in the 
near future.

I personally think this is the wrong descision. I’m aware that you
want to cater to as many clients as possible,
but you also want to ship a solid and secure product. What people see
and care about when they surf from
XP machines using RC4 or 3DES is this nice green padlock in the
browser bar. What they actually get as
security are ciphers that have been considered insecure in academia
for now over 15 years.



3DES isn't broken.
RC4 is broken, but I am yet to see a practical attack that doesn't 
require gigabits of traffic.
Again, this is the tradeoff between what academia thinks is secure, and 
the level of security
users need. It's more important for us to allow Chinese users to 
download Firefox, than it is

to disable RC4 (that westerners almost never use anyway).

Same goes for the recommendation to use DH parameters  1024 bits. 
We tried using a 2048
bits parameter a few months back. We first noticed a big spike in 
CPU usage, caused by
the largest exponentiation, but that was still acceptable. What 
forced the rollback is
the long list of java 6 clients that broke, because they don't 
accept DH keys  1024 bits.
Until all of these clients get fixed, DH params will be limited to 
1024 bits.

As far as I know stronger DH params are supported by the Java Crypto
Extensions package. That said
it’s usually not deployed anywhere. We’re aware of the issue

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2014-01-02 17:12, Ryan Sleevi wrote:

On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote:

 Hi Aaron,

 On 2014-01-02 16:10, Aaron Zauner wrote:
 Hi Kurt,

 On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote:

 On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
 I *think* they want to prefer CAMELLIA to AES, judging by the
 published ciphersuite.
 But the construction must be wrong because it returns AES 
first.

 If the intent is to
 prefer Camellia, then I am most interesting in the rationale.
 Thanks for reporting this!

 Yes. The intent was to prefer Camellia where possible. First off 
we

 wanted to have more diversity. Second not everybody
 is running a sandybridge (or newer) processor. Camellia has 
better

 performance for non-intel processors with about the
 same security.

 I would argue that our documents target server configurations, 
where

 AES-NI is now a standard.


I would have to disagree here. The two largest users of NSS, by *any*
measure, are Firefox and Chromium, both of which use it as a client.
Further, the notion of server configurations is further muddied by
efforts such as WebRTC, which sees a traditional client (eg:
heterogeneous configurations and architectures) acting as both a DTLS
client and a DTLS server.

NSS in server mode is so full of sharp edges and so few code examples 
that

I'd strongly discourage it being used as the reference for what NSS
SHOULD do.



Sorry for the confusion. By our documents, I meant:
* https://wiki.mozilla.org/Security/Server_Side_TLS
* https://bettercrypto.org/

And not NSS in client mode.

Your point about WebRTC making the client a server is interesting 
though.

Which ciphers preferences will the server use ?




 What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla 
Sec.

 Team by the way?

 There are 5 security teams at Mozilla, so Mozilla Sec Team is a 
very

 large group.
 I think we all want a new stream cipher in TLS to replace RC4. But
 that's going
 to take years, and won't help the millions of people who don't 
replace

 their software
 that often.


Really? If anything, Firefox and Chromium have shown that new changes 
can
be deployed on the order of weeks-to-months, and with server opt-in 
(such
as NPN/ALPN), the majority of *users* traffic can be protected or 
enhanced

within a few weeks-to-months after.

Google already has deployed experimental support, for example. 
Likewise,
the adoption of SPDY - within Firefox and within a number of 
significant
web properties - show that it's significantly quicker than it used to 
be

to protect users.

You're correct that there's going to be a long-tail of sites that 
don't
update, sure, but rapid deployment is certainly an increasing 
possibility

for the majority of users.



There is the case of old clients that don't upgrade, and the case of 
servers.


The reality on the server side isn't that bright, I'm afraid. Upgrading
server components is still slow and difficult. I've been trying to find
commercial systems that support the full blend of TLS features, and 
failed.


Chances are that even if new ciphers make it into TLS1.3, they won't be
widely deployed in any production environment for another 3 to 5 years.
After all, TLS 1.2 was standardized in 2008, and we're just starting to 
see it.




  From an Operations Security point of view, the question is: how do 
we

 provide the
 best security possible, with the cards we currently have in our 
hands,

 and without
 discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in 
the

 short term.

 - Julien


I strongly, vehemently disagree with that conclusion. Solutions like
ChaCha20/Poly1305 are able to reach a broad spectrum of users near
immediately and ubiquitously, providing meaningful security and speed
improvements to users. If the idea is that no solution is a good 
solution

until it's a ubiquitous solution, well, that's just silly and not
reflective of the world we live in at all.



That is not what I meant. I simply wanted to point out that, on the 
operational

side, changes and improvements are *a lot* slower to propagate.
Even if ChaCha2020/Poly1305 are deployed in Firefox and Chrome 
tomorrow, we won't
have them on the server side for a while. And when we do, there will 
still be a lot
of users who don't use it. Look at the percentage of users who 
negotiate ECDHE with

AES-GCM, for example.

Don't get me wrong: it's a critical improvement to make. But in the 
meantime,
we still need to find the best security trade offs for the remaining 
80%. And, sadly,

for some people, that means using RC4 or 3DES.

- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2014-01-02 17:12, Ryan Sleevi wrote:

On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote:

 Hi Aaron,

 On 2014-01-02 16:10, Aaron Zauner wrote:
 Hi Kurt,

 On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote:

 On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
 I *think* they want to prefer CAMELLIA to AES, judging by the
 published ciphersuite.
 But the construction must be wrong because it returns AES first.
 If the intent is to
 prefer Camellia, then I am most interesting in the rationale.
 Thanks for reporting this!

 Yes. The intent was to prefer Camellia where possible. First off we
 wanted to have more diversity. Second not everybody
 is running a sandybridge (or newer) processor. Camellia has better
 performance for non-intel processors with about the
 same security.

 I would argue that our documents target server configurations, where
 AES-NI is now a standard.


I would have to disagree here. The two largest users of NSS, by *any*
measure, are Firefox and Chromium, both of which use it as a client.
Further, the notion of server configurations is further muddied by
efforts such as WebRTC, which sees a traditional client (eg:
heterogeneous configurations and architectures) acting as both a DTLS
client and a DTLS server.

NSS in server mode is so full of sharp edges and so few code examples that
I'd strongly discourage it being used as the reference for what NSS
SHOULD do.



Sorry for the confusion. By our documents, I meant:
* https://wiki.mozilla.org/Security/Server_Side_TLS
* https://bettercrypto.org/

And not NSS in client mode.

Your point about WebRTC making the client a server is interesting though.
Which ciphers preferences will the server use ?




 What’s the take on the ChaCha20/Poly1305 proposal by the Mozilla Sec.
 Team by the way?

 There are 5 security teams at Mozilla, so Mozilla Sec Team is a very
 large group.
 I think we all want a new stream cipher in TLS to replace RC4. But
 that's going
 to take years, and won't help the millions of people who don't replace
 their software
 that often.


Really? If anything, Firefox and Chromium have shown that new changes can
be deployed on the order of weeks-to-months, and with server opt-in (such
as NPN/ALPN), the majority of *users* traffic can be protected or enhanced
within a few weeks-to-months after.

Google already has deployed experimental support, for example. Likewise,
the adoption of SPDY - within Firefox and within a number of significant
web properties - show that it's significantly quicker than it used to be
to protect users.

You're correct that there's going to be a long-tail of sites that don't
update, sure, but rapid deployment is certainly an increasing possibility
for the majority of users.



There is the case of old clients that don't upgrade, and the case of 
servers.


The reality on the server side isn't that bright, I'm afraid. Upgrading
server components is still slow and difficult. I've been trying to find
commercial systems that support the full blend of TLS features, and failed.

Chances are that even if new ciphers make it into TLS1.3, they won't be
widely deployed in any production environment for another 3 to 5 years.
After all, TLS 1.2 was standardized in 2008, and we're just starting to see 
it.




  From an Operations Security point of view, the question is: how do we
 provide the
 best security possible, with the cards we currently have in our hands,
 and without
 discarding anybody. ChaCha20/Poly1305 isn't gonna help with that in the
 short term.

 - Julien


I strongly, vehemently disagree with that conclusion. Solutions like
ChaCha20/Poly1305 are able to reach a broad spectrum of users near
immediately and ubiquitously, providing meaningful security and speed
improvements to users. If the idea is that no solution is a good solution
until it's a ubiquitous solution, well, that's just silly and not
reflective of the world we live in at all.



That is not what I meant. I simply wanted to point out that, on the 
operational

side, changes and improvements are *a lot* slower to propagate.
Even if ChaCha2020/Poly1305 are deployed in Firefox and Chrome tomorrow, we 
won't
have them on the server side for a while. And when we do, there will still 
be a lot
of users who don't use it. Look at the percentage of users who negotiate 
ECDHE with

AES-GCM, for example.

Don't get me wrong: it's a critical improvement to make. But in the 
meantime,
we still need to find the best security trade offs for the remaining 80%. 
And, sadly,

for some people, that means using RC4 or 3DES.

- Julien

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2014-01-02 18:59, ianG wrote:

On 3/01/14 01:06 AM, Julien Vehent wrote:



3DES isn't broken.



No, but it is end of life.  112bit security for the 2key variant, and an 8 
byte block makes it just old.  If you've got AES there, use it.  Who hasn't 
got it?


See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
Internet Explorer uses the cryptographic library “schannel”, which is OS 
dependent. schannel supports AES in Windows Vista, but not in Windows XP.






RC4 is broken, but I am yet to see a practical attack that doesn't
require gigabits of traffic.



What is a real concern is RC4.  Anything done to move away from that has 
to be a good thing.  The recent talk by DJB has some real fun descriptions 
of just how crappy it is becoming.


http://financialcryptography.com/mt/archives/001461.html

The way I read it, trouble starts at 2^24, that's 16M.  By the time you 
get to 2^30 or 1G it's all over...  Caveat -- I'm working from the graphs 
described from p49 of the talk, I don't pretend to understand them other 
than what the pictures say.




Again, this is the tradeoff between what academia thinks is secure, and
the level of security
users need. It's more important for us to allow Chinese users to
download Firefox, than it is
to disable RC4 (that westerners almost never use anyway).



Hmmm..  Are the Chinese blocked from stronger crypto?




According to http://www.modern.ie/ie6countdown:
 * 22.2% of China uses IE6
 * 4.9% of users worlwide use IE6

I believe that our jobs, as security professionals, is to provide the best 
security to everyone. Not only to the people that have a better access to 
technology.
This is consistent with Mozilla's mission. So we won't disable old crypto 
algorithms because the security community admits that they are bad. We have 
to live with them.


Again, site owners are free to make their own decisions. This isn't an 
unbreakable rule. At Mozilla, for example, the persona websites are unusable 
with old browsers anyway, so it makes sense to enable stronger TLS on that 
one specifically.



Same goes for the recommendation to use DH parameters  1024 bits. We
tried using a 2048
bits parameter a few months back. We first noticed a big spike in CPU
usage, caused by
the largest exponentiation, but that was still acceptable. What
forced the rollback is
the long list of java 6 clients that broke, because they don't accept
DH keys  1024 bits.



Java 6 is covered in mud all over, crypto wise.  Maybe time for some nasty 
words to start circulating.




Until all of these clients get fixed, DH params will be limited to
1024 bits.

As far as I know stronger DH params are supported by the Java Crypto
Extensions package. That said
it’s usually not deployed anywhere. We’re aware of the issue but
using DH parameters of 1024 bits only
can provide security that is slightly less than 1024bit RSA which can
certainly be factored by large agencies.
- It takes you about 48hours to factor 512bit RSA keys in EC2:
http://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf
- The largest Key factored by public research (in a small university
setup!) is currently at 768 bits: http://eprint.iacr.org/2010/006

We hope that Java will adopt a reasonable security policy in the
future, although I’m personally not conviced that they will.



Problem here is that it isn't so much 'Java' it's more the platforms. 
Android is stuck on Java 6, and the JCE choices aren't even that modern.


http://financialcryptography.com/mt/archives/001450.html

Mac OSX has now bailed from Java directly, so one gets it from Oracle/sun 
directly, which means Java 7.




For us, it's a choice between DHE with 1024, or no DHE at all. We will
not block a subgroup
of users because they don't support larger keys. And I suspect no
business ever will.

So, on DHE vs !DHE, here's the rationale:

RSA key rotations happen very rarely in hosting environments. Except
when the CA requires it,
it's not uncommon to see private keys that are several years old. Keys
also move very easily,
end up in people's mailboxes or shared folders, or get stored in cloud
providers that don't
zero their disks after use.

 From an operational perspective, the risk of leaking a RSA private key
is many times higher than
the risk of factoring a DHE key exchange. Even if this key exchange uses
half the key size of the
RSA key.

If an organization wants to spy on Mozilla's DHE traffic, they need to
factor *every single key exchange*.
On a normal day, that's hundreds of thousands of them. I'm quite certain
that the biggest security
agencies have clusters than can factor a 1024 DHE key within minutes,
but it's still a lot harder
and more targeted than factoring one single 2048 RSA key that is used
for 5 years.

For this reason, we recommend DHE with 1024 bits parameters, and RSA
2048 keys for authentication.



I agree with that.



I *think* they want to prefer CAMELLIA to AES, judging by the
published ciphersuite

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2014-01-03 12:58, ianG wrote:

On 3/01/14 19:24 PM, Julien Vehent wrote:

On 2014-01-02 18:59, ianG wrote:

On 3/01/14 01:06 AM, Julien Vehent wrote:



3DES isn't broken.



No, but it is end of life.  112bit security for the 2key variant, and
an 8 byte block makes it just old.  If you've got AES there, use it.
Who hasn't got it?


See https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
Internet Explorer uses the cryptographic library “schannel”, which is
OS dependent. schannel supports AES in Windows Vista, but not in Windows
XP.



Right, Windows XP.  Which is end of life.


Microsoft killing support for a product isn't the same thing as people 
throwing away their computers.


Or, are you implying that because microsoft is ending the life of XP, we 
should feel comfortable disconnecting these people from the internet? I'm not 
sure what they did to deserve that, except spending thousands of dollars on a 
computer years ago.






Hmmm..  Are the Chinese blocked from stronger crypto?


According to http://www.modern.ie/ie6countdown:
  * 22.2% of China uses IE6
  * 4.9% of users worlwide use IE6



Thanks for that!  More end of life.  And DJB says it's worse, we've 
retrograded to about 50% RC4 usage.




Apples and Oranges. Some websites owners prefer RC4 for various reasons, but 
it's different from what clients can actually negotiate.
Even if all website owners update their ciphersuite tomorrow, that won't 
replace the millions of computers than are stuck on RC4 and 3DES.



I believe that our jobs, as security professionals, is to provide the
best security to everyone.



That is mozilla's mission.  It provides its products to everyone.  Which 
naturally means it cannot and does not provide the 'best security' to every 
person, rather it provides the best 'security for everyone'.


Different story -- one moves security up, at the expense of users, the 
other keeps users happy, but puts security on a race to the bottom.




Not only to the people that have a better
access to technology.
This is consistent with Mozilla's mission.


Absolutely!  I'm well familiar of how the monolith of Mozilla's mission 
casts a shadow over security.


BetterCrypto however is seeking ... *better crypto*.  And that is a 
different goal.  Different users, different tradeoffs.


Where the two groups part company is on bad crypto.  If IE6 and XP users 
have bad crypto, then BetterCrypto is not for them.



So we won't disable old
crypto algorithms because the security community admits that they are
bad. We have to live with them.



Sure.  And to some extent I don't disagree -- K6 speaks to ease of use and 
availability;  it is the number one, dominating law for security.


But the enemy of cryptography is time;  what was secure then is not now.  
It doesn't take much to deal with it, but unfortunately the powers that be 
SSL have fiddled around adding more and not chopping away. Always because 
someone wants to keep it around.




This is a rock and a hard place.  The rock of upgrading has met the hard 
place of legacy users.


Where this goes from here is tension:  BetterCrypto and groups like it 
will continue to deprecate those ciphers.  Users will start to suffer. Users 
will complain.  Mozilla and browsers and so forth will cop the brunt of the 
suffering.  Very unfair.


But meanwhile the fix is in.  And if there is one thing we do know, the 
juggernaut of SSL/IETF/PKIX/CABForum/OpenSSL/NSS/NIST/Sun/ and a dozen other 
acronyms I've forgotten ... are not going to push on this front. They are 
going to do what they always do:  act as if every old cipher is like a limb, 
squealing and moaning at the thought that it is going to be cut off, all the 
while salivating at the chance to add another cipher suite, more, moar!


:) prove me wrong!  See how long it takes to get any of those groups of 
power to announce an end of life for RC4.  Or 3DES.  Bloody android is still 
using MD5, last I heard...




BetterCrypto *has to lead* because everyone else is following each other 
in a big circle.




iang



I'm not sure what, in my message, triggered such a strong reaction. As I 
said in a previous email:



1. I think it's great to have two guides with divergent points of view. 
I'm mostly
   interested in discussing design choices, because these discussions 
are useful.
   I'm not interested in convincing the ACH group that one 
recommendation is better

   than the other, since it completely depends on the context.


If anyone has a secret sauce to replace all of the ancient software out 
there, with newer one that support TLS1.2, OCSP Stapling and so on, I'm 200% 
up for it.
In the meantime, it's important that users can reach mozilla.org from IE6, 
so that they can install Firefox and enjoy stronger security.


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [Ach] Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2014-01-03 16:09, Falcon Darkstar Momot wrote:


If  I may weigh in, one could certainly argue that there isn't any benefit 
in allowing these people to believe that their HTTPS connections are 
actually secure when they're using ciphers that we know to be broken (how 
much we know them to be broken is certainly up for debate).




Even with RC4 or 3DES, that HTTPS icon still tells a user that their abusive 
relative can't read their emails on the house's proxy. What we, security 
professional, define as secure is widely different from what the average user 
wants or needs.


People can still go to whatever site they want even if they can't use 
HTTPS, as long as the site is available over HTTP.


What if the NSA could break all crypto in the world within seconds? Would we 
accept to type our passwords and emails over HTTP then?  I suspect not.


I wouldn't bother actually dropping support for a cipher suite until it 
can be trivially broken, though, as that is the point at which it has no 
value.  Anything else is excessively heavyhanded.


--FalconK


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On 2014-01-09 06:41, Kurt Roeckx wrote:
I'm considering if we should also drop support for RC4 on the client side. 
At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES.


I started a scan of Alexa's top 1 million websites. It's going to take a few 
days to have all the results.

So far, 21 out of 1396 websites scanned support neither AES or 3DES.

All of these sites are high traffic:

lynda.com
priceline.com
adultfriendfinder.com
siteground.com
lacaixa.es
mmotraffic.com
hostmonster.com
elance.com
vine.co
cvs.com
tharunaya.co.uk
directv.com
goal.com
bluehost.com
typepad.com
inbox.com
sprint.com
squarespace.com
justhost.com
123rf.com
hostgator.com

The (partial) results are here: http://4u.1nw.eu/top1m_ciphersuite_scan.tar
I'll do more number crunching once the scan is done.

The numbers show that deprecating RC4 in Firefox would have real impact on 
big websites. Whether we think that's a good or bad thing is up for 
discussion :)


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Julien Vehent]

On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote:

I started a scan of Alexa's top 1 million websites. It's going to
take a few days to have all the results.
So far, 21 out of 1396 websites scanned support neither AES or 3DES.


I'm about half way through the scan, but it's unlikely that the numbers will 
change from now. The raw results are below, and I posted an analysis on my 
blog: https://jve.linuxwall.info/blog/index.php?post/TLS_Survey



SSL/TLS survey of 317270 websites from Alexa's top 1 million

Supported Ciphers Count Percent
-+-+---
3DES  29762593.8081
3DES Only 3952  1.2456
AES   29040991.5337
AES Only  298   0.0939
CAMELLIA  12030237.9179
CAMELLIA Only 1 0.0003
RC4   28213988.9271
RC4 Only  4838  1.5249
z:ADH-DES-CBC-SHA 651   0.2052
z:ADH-SEED-SHA418   0.1317
z:AECDH-NULL-SHA  1 0.0003
z:DES-CBC-MD5 38276 12.0642
z:DES-CBC-SHA 88306 27.8331
z:DHE-DSS-SEED-SHA1 0.0003
z:DHE-RSA-SEED-SHA55195 17.3969
z:ECDHE-RSA-NULL-SHA  1 0.0003
z:EDH-DSS-DES-CBC-SHA 6 0.0019
z:EDH-RSA-DES-CBC-SHA 82910 26.1323
z:EXP-ADH-DES-CBC-SHA 451   0.1422
z:EXP-DES-CBC-SHA 68527 21.599
z:EXP-EDH-DSS-DES-CBC-SHA 6 0.0019
z:EXP-EDH-RSA-DES-CBC-SHA 60199 18.9741
z:EXP-RC2-CBC-MD5 73301 23.1037
z:IDEA-CBC-MD55248  1.6541
z:IDEA-CBC-SHA37419 11.7941
z:NULL-MD5291   0.0917
z:NULL-SHA290   0.0914
z:NULL-SHA256 5 0.0016
z:RC2-CBC-MD5 43848 13.8204
z:SEED-SHA65974 20.7943

Supported Handshakes  Count Percent
-+-+---
DHE   18873959.4884
ECDHE 67560 21.2942

Supported PFS Count Percent  PFS Percent
-+-++---
DH,1024bits   18520058.373   98.1249
DH,1539bits   1 0.0003   0.0005
DH,2048bits   2751  0.8671   1.4576
DH,3072bits   2 0.0006   0.0011
DH,3248bits   2 0.0006   0.0011
DH,4096bits   990.0312   0.0525
DH,512bits580.0183   0.0307
DH,768bits628   0.1979   0.3327
ECDH,B-163,163bits240.0076   0.0355
ECDH,B-233,233bits236   0.0744   0.3493
ECDH,B-571,570bits249   0.0785   0.3686
ECDH,P-224,224bits3 0.0009   0.0044
ECDH,P-256,256bits66920 21.0924  99.0527
ECDH,P-384,384bits780.0246   0.1155
ECDH,P-521,521bits940.0296   0.1391
Prefer PFS19455461.3213  0
Support PFS   23999775.6444  0

Supported Protocols   Count Percent
-+-+---
SSL2  59615 18.79
SSL2 Only 280.0088
SSL3  31605299.6161
SSL3 Only 3539  1.1155
TLS1  31339998.7799
TLS1 Only 557   0.1756
TLS1.110042531.6529
TLS1.210361232.6574
TLS1.2 Only   3 0.0009
TLS1.2 but not 1.18338  2.628


---
Julien Vehent
http://jve.linuxwall.info
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Sites which fail with tls 1.0

[Julien Vehent]

On 2014-01-27 17:22, cl...@jhcloos.com wrote:

In case anyone is keeping a list, while helping a relative I determined
that timewarnercable.com's login server (wayfarer.timewarnercable.com)
will not work with tls 1.1 or 1.2.  The connection fails after the client
right after the client hello.



A small number of sites have bad security settings. Here's some stats.

Supported Protocols   Count Percent
-+-+---
SSL2  85447 18.9264
SSL2 Only 380.0084
SSL3  44986499.6443
SSL3 Only 4443  0.9841
TLS1  44657598.9158
TLS1 Only 736   0.163
TLS1.114526632.1762
TLS1.1 Only   1 0.0002
TLS1.214992133.2073
TLS1.2 Only   5 0.0011
TLS1.2 but not 1.111888 2.6332


I had to set security.tls.version.max to 1 to get ff (26) or sm (2.23)
to get her (relevant) profile to log in to their site.


Are you saying that the default settings were failing entirely, and you had 
to force tls1 for this site?




[Side note:  +\inf on the concecpt of profiles; one of Gecko's most
 important features!]
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6




- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Where are others SHA256 cipher suits in Firefox 27?

[Julien Vehent]

On 2014-03-23 11:43, gegard4321 wrote:
Another reason to enable DHE_RSA_AES_*_GCM: Mozilla's new account 
system only

supports RSA and DHE_RSA ciphers:
https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com
Same goes for mozilla.org and bugzilla.


On the server side, we are working to support better TLS. See this 
Tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=901393


Depending on the technology used, not all ciphers are available on all 
sites. But I can already tell you that accounts.firefox.com will support 
ECDHE and AES-GCM.


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Updates to the Server Side TLS guide

[Julien Vehent]

On 2014-10-21 19:20, Julien Pierre wrote:

I wasn't even specifically referring to cipher strings, but the whole
document seems to be about servers running OpenSSL, though I did see 
a

few references to GnuTLS as well.
There are also servers running NSS, Microsoft SSL stacks, proprietary
SSL stacks, etc.


Out of the 8 configuration examples listed in [1], 4 are openssl 
specific, 3 are proprietary, one is an entire tls stack entirely.


Specifying a ciphersuite with a deterministic ordering is impossible to 
do in GnuTLS. NSS is very rarely used in servers. OpenSSL dominates that 
ecosystem, so it is natural that the document would use its syntax.


- Julien

[1] 
https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Updates to the Server Side TLS guide

[Julien Vehent]

On 2014-10-22 08:02, Hubert Kario wrote:

So, any comments to the proposed changes in opening mail?


Yes :) But I haven't had any spare cycles yet... It's on the todo list!

- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Updates to the Server Side TLS guide

[Julien Vehent]

Thank you Hubert from starting this discussion. I think this can be the 
base for version 4 of the document.


On 2014-10-20 08:10, Hubert Kario wrote:

The items that probably should be changed or added:
 * curves weaker than secp256r1 - I think they shouldn't be
   enabled at all - while browsers do enable only the two or three
   NIST curves, clients that use OpenSSL enable also the rather weak
   163 bit curve, making it possible to negotiate them (and as such
   limit the level of security to about 80 bit)


I agree. The document currently recommends secp256r1, secp384r1 and 
secp521r1. It would be good to have a more comprehensive list of curves, 
and have another list of discarded curves in the Mandatory discards 
section. The problem is being able to specify these curves in 
configurations, which isn't widely supported in servers.



 * negotiation of curves in ECDHE - servers in general should
   be able to negotiate the used curve for this KEX - it's a RFC MUST


Could you clarify what you mean by 'negotiate' ? Do you mean that 
servers should implement configurable lists of supported curves?



 * lack of secp256r1 intolerance - servers that hardcode this
   curve may ignore the tls extension completely, causing the 
connection
   to fail if the client doesn't support this curve (the server 
should

   choose a cipher that doesn't require ECC in such case)


This is the same problem we have with 2048 DHE parameters and Java 6, 
where the client fails the handshake instead of falling back to a 
non-DHE cipher. In this situation, I believe that the role of the guide 
is to inform operators on the issue and what configuration they should 
pick.


Servers should patch their TLS stacks, but that's hardly something we 
can address in the wiki...



 * SHA1 signing of (EC)DHE in TLSv1.2 - there's a bug in OpenSSL that
   causes the SNI certificate selection to not copy acceptable 
signature

   algs properly, this causes it to sign the key exchange using SHA1.
   Some servers may just hardcode the sig alg, which would be just as 
bad


That is also a server problem. What do you propose we add to the 
document to address this?



 * SHA-384 and SHA-512 signatures in certs - in current version
   they are not acceptable - as they are stronger, I think they 
should

   be added as acceptable (but maybe marked as not recommended).
   SHA-224 should probably be explicitly marked as non recommended as
   it is not supported in some libraries that do support SHA-256 and
   greater (very old NSS had this issue)


I'm not against, modulo verification that these signatures work with 
all the intended clients described in Oldest compatible client of each 
level. We should also list the clients that are not compatible.


I wonder if this is really useful though. Server Side TLS is a 
pragmatic guide, and pragmatism dictates that operators should use 
SHA-256 certs, not SHA-384 or SHA-512. When asked to review a production 
site that runs a SHA-512 cert, I would recommend the admins to downgrade 
to SHA-256 to prevent unknown behavior with unknown clients.



 * ECDSA certs (and prioritisation of ECDSA above RSA) - there's no
   mention of those, and since we suggest PFS over non-PFS and
   ECDHE-ECDSA is over twice as fast as ECDHE-RSA[1], I think we
   definitely should allow (if not recommend) its use


Same comment as above: we first need to evaluate compatibility of 
clients.
Having ECDSA in the recommended ciphersuites has no site effect on 
server compatibility. But recommending ECDSA certificates does have 
strong side effects.


Do you know of certificate authorities that issue ECDSA certs?


 * intolerance of TLS1.3 ClientHello - new version is incoming
   while a significant percentage of servers can't do TLS version
   negotiation properly


Let's leave this aside for now. TLS1.3 will not be implemented for many 
more months, and we don't know much about its structure yet. I don't 
want to confuse operators with recommendations that don't map to 
anything yet.



While most of those items may become issues only in future, I think
it's better to point to them now, so that the number of
servers that have bad configurations/bugs is limited. As such,
it will also limit the need for clients to do the TLS downgrade 
dance.


I never envisioned Server Side TLS as an implementation guide. I always 
thought of it as an operation guide. Many of your comments imply that we 
need a modern and reliable TLS implementation guide for servers, which I 
agree with, but maybe that should be a separate document that can dive 
into sample code and coding guidelines?


Even better, something similar to the Configuration Generator, but for 
code: http://mozilla.github.io/server-side-tls/ssl-config-generator/


I agree that we need to cover more of TLS, but we also must keep the 
guidelines focused on what operators need to know and can use quickly.


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org

Re: HSTS handling incorrect

[Julien Vehent]

It may be best to report it on bugzilla. That link should go to the 
right component: 
https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=nobody%40nss.bugs_file_loc=http%3A%2F%2F_ignored=0_severity=normal_status=NEW=Libraries=autodetect=text%2Fplain_groups=1_name=enter_bug=Remember%20values%20as%20bookmarkable%20template_sys=Linux=--=NSS_platform=x86_64



On 2015-10-02 17:45, Arthur Ramsey wrote:

It seems like the handling of HSTS is incorrect in Firefox on Linux
Mint per RFC6797 11.4.1,
https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
and when compared to Google Chrome.  I don't have the
includeSubDomains flag set in the Strict-Transport-Security HTTP
header, but Firefox upgrades the connection when I connect to the
server on TCP 443 (Nginx) or TCP 8080 (Jenkins).  The header is only
set when connecting on TCP 443, so it should only be upgraded on TCP
443 unless I have the includeSubDomains flag set in the
Strict-Transport-Security HTTP header and I don't.

I tested the behavior on Firefox 40.0.3 and Firefox 41.0 for Linux
Mint and it incorrect, but the same versions for Windows 7 x64 work
correctly.

I reported  it to
Linux Mint.  It doesn't appear to happen in the upstream Ubuntu.

I'm injecting the header via Nginx with the following configuration.

add_header Strict-Transport-Security "max-age=63072000; preload";
add_header Public-Key-Pins "pin-sha256=\"[% ca_sha256_base64 %]\";
max-age=2592000\"";

Can someone help me verify the issue?

Thanks,
Arthur


This e-mail and any attachments may contain CONFIDENTIAL information,
including PROTECTED HEALTH INFORMATION. If you are not the intended
recipient, any use or disclosure of this information is STRICTLY
PROHIBITED; you are requested to delete this e-mail and any
attachments, notify the sender immediately, and notify the Mediture
Privacy Officer at privacyoffi...@mediture.com.


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: AES-256 vs. AES-128

[Julien Vehent]

On 2015-11-30 12:47, Robert Relyea wrote:
I've always found the 128 bit prioritized over 256 a silly 
recommendation, I support reordering.


Can you expand on why you think it is silly?

The original thread [1] had a long discussion on this topic. The DJB 
batch attack redefines the landscape, but does not address the original 
concerns around AES-256 resistance. To me, the main question is to 
verify whether AES-256 implementations are at least as resistant as 
AES-128 ones, in which case the doubled key size provides a net benefit, 
and preferring it is a no-brainer.


[1] 
http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html


- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Error while verifying MAR with NSS

[Julien Vehent]

After further investigating, some help from Franziskus, and
rebuilding Firefox on my local machine, it would appear the issue
was caused by using a version of signmar/libmar/nss built for a
different platform. The version I just rebuilt verifies MAR
signatures without issue:

$ 
LD_LIBRARY_PATH=/home/ulfr/src/hg.mozilla.org/firefox/obj-x86_64-pc-linux-gnu/config/external/sqlite/
 \

/home/ulfr/src/hg.mozilla.org/firefox/obj-x86_64-pc-linux-gnu/dist/bin/signmar
-d . -n testmar -v /tmp/resigned.mar

$ echo $?
0

- Julien

On Tue 19.Jun'18 at  8:50:46 -0400, Julien Vehent wrote:
> Hi everyone,
> 
> I'm reimplementing Firefox MAR signature and would like to verify those
> signatures with signmar. Signmar uses NSS on Linux, and I'm running into
> issues getting it to work. Below are the steps to reproduce:
> 
> Take a signed MAR file from https://ulfr.io/f/resigned.mar and a public
> RSA key in a self-signed cert from https://ulfr.io/f/resigned_rsa.der.
> 
> Import the cert into a fresh NSS DB using:
> 
> $ certutil -d . -A -i resigned_rsa.der -n "testmar" -t ",,u"
> 
> This creates pkcs11.txt, key4.db and cert9.db in the current directory.
> 
> `certutil -d . -L` shows the cert has been added, but trust attributes
> remain empty, and I'm unsure if this is an issue.
> 
> At any rate, when I try to verify the signature with signmar, I get:
> 
> $ signmar -d . -n testmar -v /tmp/resigned.mar 
> ERROR: Could not initialize NSS
> ERROR: Could not initialize crypto library.
> 
> Looking through the source of libmar, the operation is failing on
> NSS_Initialize [1]:
> 
> NSS_Initialize(NSSConfigDir, "", "", SECMOD_DB, NSS_INIT_READONLY);
> 
> Given SECMOD_DB, I tried recreating the NSS db with `-d dbm:.` to create
> an old-style database instead of the sql one. The result is the same,
> but strace shows that signmar accesses secmod.db before failing [2].
> 
> At this point, I'm guessing the issue in in the NSS initialization step,
> but I'm not familiar enough with it to debug it further. Any help would
> be greatly appreciated.
> 
> Thanks,
> Julien
> 
> [1] 
> https://searchfox.org/mozilla-central/source/modules/libmar/sign/mar_sign.c#34-45
> [2] 
> https://gist.github.com/jvehent/53c0b43dd6fe2626f7f7d69d1b94d02e#file-signmar-strace-L361
> 
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Error while verifying MAR with NSS

[Julien Vehent]

Hi everyone,

I'm reimplementing Firefox MAR signature and would like to verify those
signatures with signmar. Signmar uses NSS on Linux, and I'm running into
issues getting it to work. Below are the steps to reproduce:

Take a signed MAR file from https://ulfr.io/f/resigned.mar and a public
RSA key in a self-signed cert from https://ulfr.io/f/resigned_rsa.der.

Import the cert into a fresh NSS DB using:

$ certutil -d . -A -i resigned_rsa.der -n "testmar" -t ",,u"

This creates pkcs11.txt, key4.db and cert9.db in the current directory.

`certutil -d . -L` shows the cert has been added, but trust attributes
remain empty, and I'm unsure if this is an issue.

At any rate, when I try to verify the signature with signmar, I get:

$ signmar -d . -n testmar -v /tmp/resigned.mar 
ERROR: Could not initialize NSS
ERROR: Could not initialize crypto library.

Looking through the source of libmar, the operation is failing on
NSS_Initialize [1]:

NSS_Initialize(NSSConfigDir, "", "", SECMOD_DB, NSS_INIT_READONLY);

Given SECMOD_DB, I tried recreating the NSS db with `-d dbm:.` to create
an old-style database instead of the sql one. The result is the same,
but strace shows that signmar accesses secmod.db before failing [2].

At this point, I'm guessing the issue in in the NSS initialization step,
but I'm not familiar enough with it to debug it further. Any help would
be greatly appreciated.

Thanks,
Julien

[1] 
https://searchfox.org/mozilla-central/source/modules/libmar/sign/mar_sign.c#34-45
[2] 
https://gist.github.com/jvehent/53c0b43dd6fe2626f7f7d69d1b94d02e#file-signmar-strace-L361

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto