Re: Intermittent Issues with 8152 Error frm NSS on SSL public / private key with PHP/Curl
all UK Bank Holidays. Support outside these hours can be arranged on request. <https://twitter.com/tassolutions> <https://www.linkedin.com/company/tas-solutions> <https://www.aito.com/aito-information/aito-business-partners> This E-mail and any attachments contain confidential and proprietary information of TAS Solutions Ltd and are intended only for the use of the person/s to whom it is addressed. If you have received this E-mail in error please immediately notify support by telephone on +44 (0)1621 857785 <+44%201621%20857785>. Although this e-mail and any attachments are believed to be free of any virus, or other defect which might affect any computer or system into which they are received and opened, internet communications cannot be guaranteed to be secure or error-free and therefore it is the responsibility of the recipient to ensure that they are virus free. The sender therefore does not accept liability for any loss or damage from receipt or use thereof which arises as a result of internet transmission. Any views/opinions expressed within this e-mail and any attachments are that of the individual and not necessarily that of TAS Solutions Ltd. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS ESNI and HelloRetryRequest in Firefox 64, Firefox Nightly
On Thursday, 3 January 2019 11:45:25 CET Alexander Venedioukhin (lists) wrote: > Hello, > > I'm implementing ESNI (encrypted SNI, current draft 02) server-side. > It works with Firefox 64.0 and Nightly 66.0a1 as expected, until the > server sends HelloRetryRequest during handshake. In latter case > Firefox responds with plain text SNI extension (same hostname) in > second ClientHello, instead of ESNI. Still, handshake successfully > finishes. Is it intended behavior? that sounds to me like a question to the IETF TLS mailing list -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using AES256 cipher directly...?
On Friday, 7 December 2018 18:24:38 CET Paul Smith wrote: > Thanks for your reply Martin! > > On Fri, 2018-12-07 at 10:46 -0500, Martin Thomson wrote: > > Unfortunately, we can't say that we have a PAKE, so I appreciate that > > you aren't able to just drop that in. > > A concern is that I have to support full backward-compatibility, not a > "flag day" upgrade, so unless a new PAKE behaves identically to my > existing SRP implementation it's probably not worth it to switch. When > I move to TLS I'll also have to maintain control of the initial > connection message, at least, to support backward compatibility... > that'll be its own brand of fun. > > > For key derivation, you probably want HKDF with SHA-256 rather than a > > straight hash function. > > Another thing that I didn't bring up: I need to implement this in other > languages (at least Java and Python), so clients can connect to the > service. So I need to consider availability in other crypto libraries > like Python ssl and javax crypto or BouncyCastle. I'm sure they have > HKDF too of course. all that sounds like something that will be very painful to do in multiple libraries; having to support two, not just one legacy implementation when the migration happens to TLS doesn't seem to me as something that will help with that (not to mention that leaving such dead and already vulnerable code is a huge liability) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Crash when importing PKCS#12 files whose certbags are encrypted with AES
On Thursday, 10 May 2018 17:46:00 CEST Jonathan Schulze-Hewett wrote: > All, > > > > I'm sure you're aware of this already, but in case you are not, Firefox/nss > crashes when it encounters a PKCS#12 file that uses AES to encrypt the > certificate bags. You can create these using OpenSSL's pkcs12 command with > the -certpbe option. Of course, it could be an issue with OpenSSL, but nss > still shouldn't crash on them. which bug is it? example files? version of NSS? version of OpenSSL? and no, there are no known interoperability issues between openssl and NSS implementation of PKCS#12 with regards to AES encryption -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Can import multiple certificates with same subject?
On Wednesday, 31 January 2018 06:43:19 CET John Jiang wrote: > In order to describing my point clearly, please consider the below simple > example. > > 1. Two certificates with same subject (CN=www.example.com) and different > nicknames (respectively, example1 and example2). Both of them are in PKCS12 > format. > > 2. Import the certificates to an existing database > $ pk12util -i example1.p12 -d sql:exampledb -W 'example1pass' > pk12util: PKCS12 IMPORT SUCCESSFU > $ pk12util -i example2.p12 -d sql:exampledb -W 'example2pass' > pk12util: PKCS12 IMPORT SUCCESSFU > > 3. List the certificates > $ certutil -d sql:exampledb -L > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > example1 > u,u,u > example1 >u,u,u > Only nickname "example1" is listed. > > 4. Display certificate example1 > $ certutil -d sql:exampledb -L -n example1 > Here, in deed, certificate example2 is displayed. > > It looks a bug. This is expected and is an artefact of the way NSS stores certificates in the database. Since a newer certificate will be used when requested by application, it should not cause any problems. > Best regards, > John Jiang > > 2018-01-31 13:07 GMT+08:00 John Jiang <john.sha.ji...@gmail.com>: > > Hi, > > I'm using NSS 3.35. > > > > With my testing, it is not allowed to import multiple certificates with > > same subject and different nicknames to a certificate database via > > pk12util. I just want to confirm this point. > > > > Best regards, > > John Jiang -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS: Unable to verify close_notify in client code?
On Tuesday, 19 December 2017 20:44:33 CET Martin Thomson wrote: > See SSL_AlertReceivedCallback(). though do note that TCP does not reliably deliver data after one side has closed connection and behaviour of different implementations varies widely (both on TCP and TLS level): https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable > On 20 Dec. 2017 6:22 am, "Johann 'Myrkraverk' Oskarsson" > > <johann@myrkraverk.invalid> wrote: > > Hi, > > > > Is it really impossible to verify if the server sent close_notify in a > > normal NSS client application? > > > > In both cases, PR_Read() returns zero with no error messages or status > > difference of any kind. > > > > I have tentatively verified that ssl3_HandleAlert() is called with > > AlertDescription zero == close_notify, using dtrace, when my server > > properly terminates the connection with PR_Close(). No such probe > > (in the client) fires if I just kill the server (naturally). > > > > My problem is that in the client code *I cannot distinguish the two* > > (with or without close_notify) in normal PR_Read() loop. There appears > > to be no publicly available API to retrieve the status of the > > recvCloseNotify flag. > > > > And the ssl3_HandleAlert code does not propagate the condition, instead > > the internal error = SSL_ERROR_CLOSE_NOTIFY_ALERT variable is simply > > ignored, and it returns with SECSuccess. > > > > This is situation is current as of changeset 14194:04fc9a90997b, > > Mon Dec 18 11:05:28 2017 +0100. > > > > How is NSS client code supposed to detect proper termination by the > > other party? > > > > I would call this a serious breach of security in the NSS public API. > > > > > > -- > > Johann | email: invalid -> com | www.myrkraverk.com/blog/ > > I'm not from the Internet, I just work there. | twitter: @myrkraverk > > -- > > dev-tech-crypto mailing list > > dev-tech-crypto@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Mozilla RSA-PSS policy
In response to comment made by Gervase Markham[1], pointing out that Mozilla doesn't have an official RSA-PSS usage policy. This is the thread to discuss it and make a proposal that could be later included in Mozilla Root Store Policy[2] I'm proposing the following additions to the Policy (leaving out exactly which sections this needs to be added, as that's better left for the end of discussion): - RSA keys can be used to make RSASSA-PKCS#1 v1.5 or RSASSA-PSS signatures on issued certificates - certificates containing RSA parameters can be limited to perform RSASSA-PSS signatures only by specifying the X.509 Subject Public Key Info algorithm identifier to RSA-PSS algorithm - end-entity certificates must not include RSA-PSS parameters in the Public Key Info Algorithm Identifier - that is, they must not be limited to creating signatures with only one specific hash algorithm - issuing certificates may include RSA-PSS parameters in the Public Key Info Algorithm Identifier, it's recommended that the hash selected matches the security of the key - signature hash and the hash used for mask generation must be the same both in public key parameters in certificate and in signature parameters - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and 64 bytes for SHA-512 - SHA-1 and SHA-224 are not acceptable for use with RSA-PSS algorithm 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1400844#c15 2 - https://www.mozilla.org/en-US/about/governance/policies/security-group/ certs/policy/ -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: OpenSSL command line to display EC key data
On Wednesday, 16 August 2017 20:41:58 CEST Roger Dunn wrote: > I have an EC key I am trying to extract the private+public key info > > I use the command line: > > openssl ec -in mykey.key.pem -noout -text > > Output is as follows: > > read EC key > Private-Key: (256 bit) > priv: 1 (0x1) > pub: > x > x > x > ASN1 OID: prime256v1 Is that pub value similar to: 04 6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296 4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5 then 1 *is* your private key value (I don't think I have to explain how bad that is...) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Specifying allowed parameter encodings in Mozilla policy
On Friday, 19 May 2017 15:57:18 CEST Gervase Markham wrote: > Brian Smith filed two issues on our Root Store Policy relating to making > specific requirements of the technical content of certificates: > > "Specify allowed PSS parameters" > https://github.com/mozilla/pkipolicy/issues/37 > > "Specify allowed encoding of RSA PKCS#1 1.5 parameters" > https://github.com/mozilla/pkipolicy/issues/38 In general I support them, but I'm afraid that the PSS specification is not detailed enough. I'd say there are 3 different places that the RSA-PSS parameters can be: 1. In the signature (certificate, CRL, S/MIME or CMS, etc.) 2. in the public key info structure of CA certificate 3. in the public key info structure of EE certificate Presence of parameters in 1 is mandatory. Presence of parameters in 2 is recommended (SHOULD in RFC 5756) and optional (MAY in RFC 5756) in 3. Given the interactions between TLS and certificates, I'd say we should suggest _against_ inclusion of them in 3. Thus the valid value would also be "absent". Second possible problem stems from the fact that saltLen is differently interpreted in signature (1) and in public key info (2, 3). In case of signature, it's the literal value. But in case of public key info it's the _minimum_ size of salt allowed. I don't think we gain anything from rejecting bigger salts, they are limited by key size anyway. To oversimplify a bit, we should be lenient for signatures made by end-user software and strict for signatures made by CA software. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: pk12util: no user certs from given nickname
On Friday, 20 January 2017 19:14:08 CET Yao, Julie wrote: > certutil –L –d config/nssdb > > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > juliek12 Cu,Cu,Cu > juliek1 Cu,Cu,Cu > soneraclass2ca CT,, > > pk12util -o /tmp/exportfile.pkcs12 -W changeit -d config/nssdb/ -K changeit > –n soneraclass2ca > pk12util: no user certs from given nickname > > If the alias is key, pk12util works fine. It fails in certs. it does look like the pk12util does not support exporting just the certificate, if you'd like this feature, I suggest opening a bugzilla feature request for exporting just certificates, you can use certutil -L with either -r or -a the resulting PEM or DER file can be converted to PKCS#12 file with `openssl pkcs12` utility > > -Original Message- > From: Hubert Kario [mailto:hka...@redhat.com] > Sent: Friday, January 20, 2017 7:11 AM > To: dev-tech-crypto@lists.mozilla.org > Cc: Yao, Julie <julie@hpe.com> > Subject: Re: pk12util: no user certs from given nickname > > On Thursday, 19 January 2017 19:51:59 CET Yao, Julie wrote: > > > When I ran certutil to list certs/keys in my nssdb, it showed a couple > > of certificates in the db. But when I tried to use pk12util to export > > one of the certificates, I got: pk12util: no user certs from given > > nickname > > > can you provide exact commands and their outputs you have used? > > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: pk12util fails to import EC keys
On Wednesday 29 June 2016 12:45:40 Chris Richardson wrote: > On 29 June 2016 at 12:02, Hubert Kario <hka...@redhat.com> wrote: > > > On Tuesday 28 June 2016 02:59:18 chrisr wrote: > > > Hi, > > > > > > I'm trying to import an EC key and cert generated with openssl into an > > NSS > > > DB but am getting this error from pk12util: > > > pk12util: PKCS12 decode import bags failed: > > > SEC_ERROR_PKCS12_UNABLE_TO_IMPORT_KEY: Unable to import. Error > > attempting > > > to import private key. > > > > > > I've tested this on Gentoo x86 with nss versions 3.23(portage), > > > 3.24(portage) and 3.25 (from source) with the same result. Changing the > > key > > > type to RSA works so I wonder if this might be bug in the EC key > > handling? > > > > > > Steps to reproduce: > > > # Create an empty NSS db > > > mkdir nss > > > openssl rand -base64 -out nss/pw 21 > > > certutil -d nss -f nss/pw -N > > > # Generate an EC key/cert > > > openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp521r1 -keyout > > > key.pem -out cert.pem -days 3650 -nodes -subj "/CN=Test CA" > > > # Export to pkcs12 format > > > openssl pkcs12 -export -in cert.pem -inkey key.pem -out cert.p12 -name > > Test > > > # Import to nss db > > > pk12util -i cert.p12 -d nss -k nss/pw > > > # pk12util reports error > > > > Using nss 3.23.0 and openssl 1.0.1 on Fedora with slightly different > > commands, > > I can't reproduce it: > > > > mkdir nssdb > > certutil -N --empty-password -d sql:nssdb/ > > openssl ecparam -out secp521r1.pem -name secp521r1 > > openssl req -x509 -newkey ec:secp521r1.pem -keyout localhost.key -out > > localhost.crt -subj /CN=localhost -nodes -batch > > openssl pkcs12 -export -passout pass: -out localhost.p12 -inkey > > localhost.key -in localhost.crt > > pk12util -i localhost.p12 -d sql:nssdb/ -W '' > > certutil -L -d sql:nssdb/ -n localhost -a | openssl x509 -noout -text > > > > so it doesn't look to me like a problem with EC keys specifically > > > > which version of OpenSSL are you using? > > > > I'm using openssl-1.0.2g. > > Your script also works on my environment so I'll switch to that method. > It looks like there is a significant difference in the keys produced by > openssl in the two cases - > your script produces a key that looks like this: > $ openssl pkey -in localhost.key -text -noout > > Private-Key: (521 bit) > > priv: > > > > pub: > > > > ASN1 OID: secp521r1 > > NIST CURVE: P-521 > > while mine produces this: > $ openssl pkey -in key.pem -text -noout > Private-Key: (521 bit) > > > > priv: > > > > > > > pub: > > > > > > Field Type: prime-field > > > > Prime: > > > > > > A: > > > > > B: > > > > > Generator (uncompressed): > > > > > Order: > > > > > Cofactor: 1 (0x1) > Seed: > > > > > > so I assume (perhaps stating the obvious) that the problem is that in the > latter case the key is a definition of the finite field in parametric form > rather than using the standard curve name and that this is not supported by > nss. yes, NSS does support only named curves, not curves in arbitrary format btw: you may want to consider using a smaller curve (like the P-384) - the P-521 is not supported by Windows or Chrome -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cipher suits, signature algorithms, curves in Firefox
On Friday 06 May 2016 10:34:37 Zoogtfyz wrote: > > the larger key size helps w.r.t. quantum computers. > > If quantum computers are currently on the level of breaking AES-128, > then they are on the level of breaking any asymmetric cryptography > (RSA, DHE or ECDHE key exchange) we are using - which makes support > for AES-256 moot. That's not correct. Grover's algorithm requires you to perform 2^(n/2) operations to break symmetric crypto, and it uses n qbits to do that. To break aes-128 you need quantum computer with 128 qbits, and 2^64 operations. To break AES-256 you need 256 qbits and 2^128 operations. To break RSA you need quantum computer which can do Shor's algorithm, which requires n*3/2 qbits and around (log n)^2 operations. So for 2048 bit RSA you need 3072 qbit QC and about 83 operations. In other words, quantum computer that breaks AES-128 can't even scratch RSA. Quantum computer that breaks AES-256 doesn't make it possible to actually recover plaintext, and it still don't break currently used RSA. > Moving away from AES-256 will put even more > pressure on the crypto community to come up with a solution as > opposed to the *relative* complacency we are seeing now. I don't think we are in the position to demand crypto community to do anything in particular... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Disabling all uses of elliptical curves
On Saturday 30 April 2016 09:05:27 Martin Thomson wrote: > At the TLS layer, you can disable all suites that require ECC. I haven't tested it, but I don't think that will stop NSS trusting RSA certificates signed by ECC CAs. > On Sat, Apr 30, 2016 at 4:40 AM, Franziskus Kiefer <fkie...@mozilla.com> wrote: > > there's no runtime option but you can disable it at compile time > > with > > NSS_DISABLE_ECC, see [1] > > > > [1] > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Refere > > nce/NSS_environment_variables> > > On Fri, Apr 29, 2016 at 3:44 PM, jonetsu <jone...@teksavvy.com> wrote: > >> Hello, > >> > >> Is there a run-time option to disable all and every uses of > >> elliptical curves ? > >> > >> If not, is there a compile option ? > >> > >> Thanks. > >> > >> > >> > >> > >> -- > >> View this message in context: > >> http://mozilla.6506.n7.nabble.com/Disabling-all-uses-of-elliptical-> >> > >> curves-tp354147.html Sent from the Mozilla - Cryptography mailing > >> list archive at Nabble.com. -- > >> dev-tech-crypto mailing list > >> dev-tech-crypto@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-tech-crypto > > > > -- > > dev-tech-crypto mailing list > > dev-tech-crypto@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RFC7512 PKCS#11 URI support
On Tuesday 05 April 2016 07:26:56 Ryan Sleevi wrote: > On Tuesday, April 5, 2016, Hubert Kario <hka...@redhat.com> wrote: > > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse > > > <dw...@infradead.org > > > > I'm sorry Ryan, but I also don't see how this would break API. > > Does that mean you don't understand the use cases and situations > outlined? Or that you don't believe they are valid use cases? Because > those are all very different statements. No, I believe that I do understand the use cases as outlined by David. And I'm very much interested in adding the PKCS#11 URI support. What is unconvincing to me is your arguments against the change. > > Stuff that didn't work previously and now will work is not something > > I would consider API or ABI break. > > We have considered such changes multiple times in the past as breaks - > most typically on Red Hat's request! This is why multiple extensions > and behaviours are disabled by default in the TLS stack right now, > even though they are strictly additive. How would you see this as any > different? Because this does not affect existing code. When some API didn't support one value, but suddenly starts accepting it, it's not an API or ABI break. That's exactly how APIs like SSL_OptionSet() were changed in the past. Did Red Hat ever say that making SSL_OptionSet() support a new option ID was an API or ABI break? The previous options being disabled by default were like this because the change would be visible by default (e.g. a new extension being present in Client Hello, likely the only extension in a TLS1.0 hello). And that does pose a problem when you have TLS version intolerant and TLS extension intolerant servers out there. PKCS#11 change is invisible for anybody using certificate nicknames that do not happen to be also valid PKCS#11 URIs. If your code can't handle PKCS#11 URIs, then it won't handle it, but it won't break any existing workflow, baring stuff like https://xkcd.com/1172/ (existing nicknames are PKCS#11 URIs). -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RFC7512 PKCS#11 URI support
On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse <dw...@infradead.org> wrote: > > Do you even have a way for a nickname to be entered in text form, > > such that you could "maliciously" be given a PKCS#11 URI instead of > > the normal "token:nickname" form? Perhaps a user could edit a > > config file? Or is it *all* selected via a GUI, as far as the user > > is concerned? > David, > > Let's work back from first principals, because you're being > self-contradictory in replies. > > As you yourself note, this change would mean that any time an > application can be introduced a "nickname" from some source (whether > an API, a configuration file, a command-line flag) suddenly has a new > semantic structure to the nickname over the present NSS. > > You present this as a positive change - all NSS using applications > don't need to change. I've tried, repeatedly, to explain to you how > that is an observable API difference. It means that nicknames supplied > (again, whatever the API) now have additional structure and form. > > Your justification seems to be that because you can't imagine my > application doing it, I shouldn't be concerned. But just re-read the > above and you can see how it affects every application - there's now a > new structure and form, and that changes how applications deal with > the API (*especially* if they did anything with that configuration > flag, which, under present NSS, is perfectly legal) > > Your change has observable differences. It breaks the API. Thus, it > makes sense to introduce a new API. An application cannot safely > assume it will 'just work' if your change was integrated - instead, > authors would need to audit every API call they interact with > nicknames from any source *other* than direct NSS calls, and see if > they're affected. > > That's simply not an appropriate way to handle API changes. I'm sorry Ryan, but I also don't see how this would break API. Stuff that didn't work previously and now will work is not something I would consider API or ABI break. I see David argumentation as completely valid and correct - this is acceptable change. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [ANNOUNCE] NSS 3.23 Release
Uint16[74]' -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS CMS and RFC 5652
On Monday 11 January 2016 15:53:26 Kai Thiele wrote: > Hi, > > regarding CMS (Cryptographic Message Syntax), > which RFC is the current one NSS is supporting ? > (e.g RFC 5652 and RFC 5753 or only RFC 2630) > > I already searched for this in the list, > but relevant entries are 5 to 10 years old. > > > I tried to decrypt a CMS container using cmsutil (NSS 3.21) > The container(signed-data) was generated by OpenSSL 1.0.1p > Keys are ECC secp256v1 and signature is ECDSA_SHA256. > > It seems that NSS is not identifying the keys as 'ecKey' > and the algorithm-ids like SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE > are ignored. That leads to error Messages from cmsutil. > > So I wonder, to which RFC the CMS in NSS is compliant. > > Thank you in advance for any information to lighten this up. > BR Kai Yes, I can confirm the bug. Will you file a bug in mozilla bugzilla against the NSS component? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS CMS and RFC 5652
On Wednesday 13 January 2016 17:43:02 Kai Thiele wrote:
> Hubert Kario redhat.com> writes:
> > On Monday 11 January 2016 15:53:26 Kai Thiele wrote:
> > > Hi,
> > >
> > > regarding CMS (Cryptographic Message Syntax),
> > > which RFC is the current one NSS is supporting ?
> > > (e.g RFC 5652 and RFC 5753 or only RFC 2630)
> > >
> > > I already searched for this in the list,
> > > but relevant entries are 5 to 10 years old.
> > >
> > >
> > > I tried to decrypt a CMS container using cmsutil (NSS 3.21)
> > > The container(signed-data) was generated by OpenSSL 1.0.1p
> > > Keys are ECC secp256v1 and signature is ECDSA_SHA256.
> > >
> > > It seems that NSS is not identifying the keys as 'ecKey'
> > > and the algorithm-ids like SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE
> > > are ignored. That leads to error Messages from cmsutil.
> > >
> > > So I wonder, to which RFC the CMS in NSS is compliant.
> >
> > Could you provide exact steps needed to reproduce this?
>
> OpenSSL create certificates (selfsigned ca-cert and SIG certificate):
> ecparam -name prime256v1 -genkey -noout -out key_priv_01.pem
> ec -in key_priv_01.pem -pubout -out key_pub_01.pem
> ecparam -name prime256v1 -genkey -noout -out key_priv_02.pem
> ec -in key_priv_02.pem -pubout -out key_pub_02.pem
> req -x509 -new -sha256 -key key_priv_01.pem -out ca-cert.pem -outform
> PEM -days 7300
> req -new -key key_priv_02.pem -out client-csr.pem
> x509 -req -days 3653 -outform PEM -inform PEM -sha256 -extfile
> client.ext -in client-csr.pem -CA ca-cert.pem -CAkey key_priv_01.pem
> -CAcreateserial -out client-cert.pem
contents of client.ext?
> pkcs12 -export -out SIG.pfx -inkey key_priv_02.pem -in client-cert.pem
> -certfile ca-cert.pem
>
> If the client/SIG-certificate contains an Extended Key Usage
> extension, then it must contain the id-kp-emailProtection OID.
> The Client/SIG-certificate is signed by the ca-certificate.
>
> OpenSSL create and verify CMS container:
> cms -sign -in test.txt -out signed.bin -inkey key_priv_02.pem -md
> sha256 -signer client-cert.pem -outform DER -nodetach -nosmimecap
> -stream cms -verify -inform DER -in signed.bin -signer
> client-cert.pem -out signedtext.txt -CAfile ca-cert.pem
>
> test.txt is a file with some text in it, like: '01234567890'
> cms - verify is only done to chek if with OpenSSL if the Container is
> good.
>
>
> NSS import certificates:
> ./certutil -A -n TstCA -t "TCu,TCu,TCu" -d /home/xxx/nss-3.21/db -p
> nss -i ../ca-cert.pem
> ./pk12util -i SIG.pfx -d /home/xxx/nss-3.21/db -p nss
>
>
> NSS decode CMS container (as Validation of signature):
> ./cmsutil -D -i ../signed.bin -o ../decode.txt -d
> /home/xxx/nss-3.21/db -p nss
>
> That ends in:
> signer 0 status = SignatureAlgorithmUnsupported
> cmsutil: problem decoding: SEC_ERROR_PKCS7_BAD_SIGNATURE: Signature
> verification failed: no signer found, too many signers found, or
> improper or corrupted data.
>
>
> If all the certificates are available to OpenSSL and NNS only the
> following lines are needed to reproduce.
>
> OpenSSL:
> cms -sign -in test.txt -out signed.bin -inkey key_priv_02.pem -md
> sha256 -signer client-cert.pem -outform DER -nodetach -nosmimecap
> -stream
>
> NSS:
> ./cmsutil -D -i ../signed.bin -o ../decode.txt -d
> /home/xxx/nss-3.21/db -p nss
>
>
>
>
> With the following changes it works:
>
> nss-3.21\nss\lib\cryptohi\secvfy.c : line 169
> static SECStatus
> decodeECorDSASignature(SECOidTag algid, const SECItem *sig, unsigned
> char *dsig,
> unsigned int len) {
> SECItem *dsasig = NULL; /* also used for ECDSA */
> SECStatus rv=SECSuccess;
>
> if ((algid != SEC_OID_ANSIX9_DSA_SIGNATURE) &&
> (algid != SEC_OID_ANSIX962_ECDSA_SHA224_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_ECDSA_SHA384_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_ECDSA_SHA512_SIGNATURE) && /* RFC
5753
> */
> (algid != SEC_OID_ANSIX962_EC_PUBLIC_KEY) ) {
> if (sig->len != len) {
> PORT_SetError(SEC_ERROR_BAD_DER);
> return SECFailure;
> }
>
> --
>
> nss-3.21\nss\lib\cryptohi\seckey.c : line 492
> seckey_GetKeyType (SECOidTag tag) {
> KeyType keyType;
>
> switch (tag) {
> ...
> case SEC_OID_ANSIX962_EC_PUBLIC_KEY:
> case SEC_OID_ANSIX962_ECDSA_SHA224_SIGNATURE: /* RFC 5753 */
>
Re: NSS CMS and RFC 5652
On Monday 11 January 2016 15:53:26 Kai Thiele wrote: > Hi, > > regarding CMS (Cryptographic Message Syntax), > which RFC is the current one NSS is supporting ? > (e.g RFC 5652 and RFC 5753 or only RFC 2630) > > I already searched for this in the list, > but relevant entries are 5 to 10 years old. > > > I tried to decrypt a CMS container using cmsutil (NSS 3.21) > The container(signed-data) was generated by OpenSSL 1.0.1p > Keys are ECC secp256v1 and signature is ECDSA_SHA256. > > It seems that NSS is not identifying the keys as 'ecKey' > and the algorithm-ids like SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE > are ignored. That leads to error Messages from cmsutil. > > So I wonder, to which RFC the CMS in NSS is compliant. Could you provide exact steps needed to reproduce this? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Adding a test only option to the NSS server to disable sending the renego extension
On Sunday 20 September 2015 23:50:56 Cykesiopka wrote: > Hi, > > As part of my work on creating tests for > https://bugzilla.mozilla.org/show_bug.cgi?id=883674, I need some way > to control whether or not the NSS server sends the renegotiation > extension. > > My current idea is to add a debug only SSL_ option for this (I have no > interest in letting such an option be used in production). > Does this sound like a reasonable solution? I don't know the code in question, but I'm afraid that it would be fairly invasive (i.e. couldn't be limited to just selfserv). Adding debug features to core parts of security software is also not a good idea (at least IMHO). Finally, this code would have to be built twice so that it could be actually tested with automated testing. now, putting a cap of the product developer: if you want to see what happens with a given TLS implementation or server when the other side doesn't meet its expectations, it should be fairly easy to extend tlsfuzzer[1] with this feature (pull requests more than welcome, and I actually do plan to work on this myself in November). 1 - https://github.com/tomato42/tlsfuzzer -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems with FF and internal certificates
On Friday 01 May 2015 12:11:00 Tanvi Vyas wrote: On Apr 27, 2015, at 2:03 PM, Michael Peterson michaelpeterson...@gmail.com wrote: Firefox does not like our internal certificates. I'm trying to figure out why... tl;dr - Our internal IIS servers, signed with our internal CA, present a Secure Connection Failed page, with technical details that say Connection Not Encrypted. The certificate is installed in Firefox's internal certificate store. Here are our certificates https://www.highlands.edu/site/is-certification-authority The root cert is self signed with SHA-512, if it uses SHA-512 also for EE certificates, you're likely hitting MZBZ#1155922 interoperability issue caused by change introduced by MS14-066 in Windows. You don't see this problem with Nginx or Apache because they send the certificate even if the extensions advertised by client don't match the certificate the server has (they let the client decide if it will trust the cert or not), OTOH, IIS decides for the client that it won't be able to handle certificate, so it doesn't send any and aborts connection without telling client why (thus the incomprehensible error message). -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default
On Monday 02 March 2015 13:51:24 Kurt Roeckx wrote: On 2015-03-02 13:32, Hubert Kario wrote: Not true. In Alexa top 1 million I found at least 439 servers which support only 3DES and have valid certificates. If Firefox removes RC4, I'm sure that this will make this number effectively only larger (80% of servers still support RC4, 15% prefer RC4 over any and all ciphers). Please note that since 36 (released last week) RC4 is not offered in the initial connection anymore. See: https://developer.mozilla.org/en-US/Firefox/Releases/36#Security https://bugzilla.mozilla.org/show_bug.cgi?id=1088915 And those stats were from 36 only? Anyway, Firefox still accepts 2048 bit RSA keys, which have approximately the same security margin as 3DES. Dropping 3DES won't make the connections more secure while it will cause connection problems to Windows 2k3 servers. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default
On Saturday 28 February 2015 01:03:39 nellie.pet...@safe-mail.net wrote: I am using Marlene Pratt's Proposal to Remove legacy TLS Ciphersuits Offered by Firefox from 13 Dec 2013 on dev-tech-crypto mailing list as a guideline. I present a proposal to remove some legacy ciphersuites from the initial handshake presented by Firefox. In Firefox 36, we have removed RC4 from the initial handshake, as well as implemented a secondary/fallback handshake for badly configured servers. I have read the updated version of best current practices regarding Recommendations for Secure Use of TLS and DTLS: https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-11 These are the default available ciphersuites in Firefox 36.0: C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 C00A TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA C009 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA C013 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA C014 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 002F TLS_RSA_WITH_AES_128_CBC_SHA 0035 TLS_RSA_WITH_AES_256_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA I propose removal of the following ciphersuite: 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA because DSS (the non-EC version) is obsolete, and based on preliminary telemetry and Pulse data is not being negotiated at all with any servers out there. My testing indicates that there are no public nor private servers that would support only this ciphersuit - please provide some data if you think otherwise. I also propose removing the following ciphersuit: 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA because 3DES is a cipher that requires too much computing power compared to AES, much more computer memory, lacks hardware acceleration on servers, is rarely negotiated, has had its bitstrenght reduced below 128bits, and its removal is on track with avoiding (and eventually removing) RSA key exchange. Additionally, the servers that support (or even prefer!) 3DES always support some AES ciphersuit too. Not true. In Alexa top 1 million I found at least 439 servers which support only 3DES and have valid certificates. If Firefox removes RC4, I'm sure that this will make this number effectively only larger (80% of servers still support RC4, 15% prefer RC4 over any and all ciphers). -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Interested in reviving PSS support in NSS
On Monday 16 February 2015 18:40:59 Hanno Böck wrote: I don't really know what channels I'd have to go through to pursue such a preset-OID. Can an OID be defined by an RFC? How does the interaction between the OID registration and RFCs work? Is this something the CFRG would do or some other entity in the IETF? OIDs in private organisation trees are defined by the organisation, so if Mozilla just publishes a document stating that such and such numbers mean this and this it's practically defined no need for involvement of any external entities to define it. But I don't think we need or even want OID in the ClientKeyExchange or ServerKeyExchange... There's just a need to define a new SignatureAlgorithm (e.g. 4) that would say rsa-pss. Then the RFC would bind specific parameter sizes to given hashes. The OID would just be an implementation detail in NSS, though it could in theory be reused for X.509. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
On Saturday 08 November 2014 10:29:06 Kosuke Kaizuka wrote: On Thu, 23 Oct 2014 01:35:08 +0900, Kosuke Kaizuka wrote: On Wed, 22 Oct 2014 00:59:53 -0700, Brian Smith wrote: On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario hka...@redhat.com wrote: The number of sites that prefer RC4 while still supporting other ciphers are very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not changing much. The percent of servers that support only RC4 is steadily dropping (1.771% in April[3], 1.194% in May[2], 0.985% in June[1]). Because of that, disabling RC4 should be possible for many users. The big exception for that was YouTube video servers[4] which only recently gained support for TLS_RSA_WITH_AES_128_GCM_SHA256. Sorry that I couldn't say more earlier, but please see this message from Adam Langley of Google about YouTube working on TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: http://www.ietf.org/mail-archive/web/tls/current/msg14112.html And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's already enabled in some locations. Excellent news! It has not enabled yet in Japan. https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-uxaxovg-5goz.googlevi deo.com TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_RC4_128_SHA Now we can use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256! Yup, it's working also in Europe. -- Regards, Hubert Kario -- 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
On Saturday 25 October 2014 14:26:59 Julien Vehent wrote: 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. AFAIK, new versions of nginx do allow to set multiple curves. New apache can also be configured to use any curves supported by openssl automatically, but AFAIK, you can't disable use of specific ones, you can force it to use one specific curve though. For a high profile server, disabling all curves but P-256 (secp256r1) may be a better solution than leaving all curves available. But if you're running your server on Fedora or RHEL, where the only curves enabled are at least 256 bit long, the automatic mode is completely fine to leave on. (it's similar to using !ADH in cipher sting, if you're running 0.9.8, it's completely fine and safe, but if you're running 1.0.1 with ECC compiled in then you may leave AECDH ciphers enabled by mistake) * 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? those are two related but different issues first is that server can support just one or a set of curves secondly, client does advertise in ClientHello a list of curves it supports, it's the elliptic_curves extension. Client there can say that it supports given curves, but not others (e.g. only the P-256, P-384 and P-521 NIST curves). Then the server knows that it can only select a curve from this set for ECDHE and can't select, e.g. P-224 even though it is faster. But what if a server assumes that all clients that support ECDHE also support NIST P-256 curve? Then it may also decide to support only P-256. That's not a problem, but only as long as it will detect clients that don't support P-256 and downgrade to a non-ECDHE connection in such case. Some servers can't do this downgrade and just abort connection. Some will just force the P-256 on client in such a situation. Both are bugs. * 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... but unlike with DHE, this time the client *does* inform the server that it won't be able to process KEX that uses curves other than what it advertises. If the server still selects such a curve, it's a bug in server. And in such a case, the server (temporarily) should be configured to support curve(s) that give the biggest client coverage but, at the same time, it should be reported, fixed and later deployed. If a server administrator doesn't know that his servers are broken, he won't fix them. Sure, the process is more complex that fixing the cipher sting, but it still is doable. * 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? The guide should be extended to information on how to detect that, and note that it requires a patch from the vendor to fix (and that you need to test every SNI host separately, not for just that bug but in general). * 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
Re: Proposal: Disable SSLv3 in Firefox ESR 31
On Wednesday 22 October 2014 15:54:57 Julien Pierre wrote: Hubert, On 10/22/2014 05:27, Hubert Kario wrote: Problem is that if something doesn't work in one browser and does in another users blame the browser. Even if the browser that doesn't work does the right thing. What if all browsers started doing the right thing ? That's a very hypothetical question... What if all servers deployed TLS1.2 and refused connections with anything older? That would also fix the problem... Recommending the use of obsolete browsers is also a bad idea - they have well known vulnerabilities. It also may simply be not possible in walled gardens (phones/tablets). Are there phone/tablets which can't install any 3rd party browsers at all ? AFAIK, iOS devices require you to use the system TLS stack. Anyway, the very fallback we are talking about here is a known vulnerability. It sounds like we want a browser that is current on vulnerability fixes, except for this one. I'm not saying it isn't. But it is behaviour that is expected by users. Just like users expect to not see this connection is untrusted, you may be subject to MITM attack when connecting over plain HTTP. This way, browsers won't subject the requests to 99.999% of servers that are not TLS-intolerant to needless MITM attacks, not to mention extra network bandwidth and round trips. It's closer to below 99% or 89%, depending on which TLS version you look at. Do you have any pointer to the versions and data for this 99% / 89% ? http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf -- Regards, Hubert Kario -- 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
On Tuesday 21 October 2014 23:09:58 Julien Pierre wrote: Julien, On 10/21/2014 18:02, Julien Vehent wrote: NSS is very rarely used in servers. Perhaps so statistically, but the products are still around. I notice that Oracle/iPlanet/RedHat products are absent from the document. Oracle still ships at the very least iPlanet Web Server, iPlanet Proxy Server, Oracle Traffic Director, which use NSS currently (I should know since I work on these). Some of these have been around for about 18 years in various incarnations, so we must be doing at least something right. There are several more as well - Messaging and Directory, which are still be maintained elsewhere within Oracle. Red Hat used to ship some servers with mod_nss , though I don't know how widely it is used. Same with RedHat CMS. I am sure others from RH can chime in. yes, RedHat does ship few products that by default use mod_nss. The dominance of OpenSSL on server side still stands, as such we should first make sure that the guide is applicable to OpenSSL and then translate it to nss based servers. As far as I know the OpenSSL feature set is a strict super set of NSS feature set (at least crypto-wise), so translation from OpenSSL to NSS is possible, not so much other way round. It's the same thing with old (0.9.8) vs new openssl... Remember that we list what is safe in general, now what needs to be disabled in OpenSSL to make it safe. So, any comments to the proposed changes in opening mail? -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
On Tuesday 21 October 2014 16:10:52 Julien Pierre wrote: Hubert, On 10/21/2014 05:06, Hubert Kario wrote: Yes, it's external to the TLS, and yes, it's bad that browsers do use the manual fallback. Yes, the servers should be regularly updated and as such bugs that cause it fixed. Yes, the configurations should be updated to align them with current recommendations. But it doesn't happen in real world. So either we can push for policies which will never be implemented and be workable in real world, or we can try to make the systems secure in real world for people that care (both users and server admins that do apply updates regularly). Yes, I'd like to live in a world where it's not necessary, but we don't. IMO, reasonable decisions can be made to drop support for TLS intolerant servers. Those who have legacy devices that can't be updated could still use legacy browsers to connect to them, or there could be an explicit legacy mode of operation in current browsers that preserves it. Problem is that if something doesn't work in one browser and does in another users blame the browser. Even if the browser that doesn't work does the right thing. Recommending the use of obsolete browsers is also a bad idea - they have well known vulnerabilities. It also may simply be not possible in walled gardens (phones/tablets). This way, browsers won't subject the requests to 99.999% of servers that are not TLS-intolerant to needless MITM attacks, not to mention extra network bandwidth and round trips. It's closer to below 99% or 89%, depending on which TLS version you look at. It's rare, but it's not unheard of, and that's internet facing dedicated web servers. I'm afraid what the statistics would be for devices where the TLS part is secondary (routers/automation systems/smart devices/etc.) which we can't really probe. -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
On Wednesday 22 October 2014 00:59:53 Brian Smith wrote: On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario hka...@redhat.com wrote: The number of sites that prefer RC4 while still supporting other ciphers are very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not changing much. The percent of servers that support only RC4 is steadily dropping (1.771% in April[3], 1.194% in May[2], 0.985% in June[1]). Because of that, disabling RC4 should be possible for many users. The big exception for that was YouTube video servers[4] which only recently gained support for TLS_RSA_WITH_AES_128_GCM_SHA256. Sorry that I couldn't say more earlier, but please see this message from Adam Langley of Google about YouTube working on TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: http://www.ietf.org/mail-archive/web/tls/current/msg14112.html And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's already enabled in some locations. Glad to hear that, I'll be impatiently waiting for it to be deployed on servers assigned to central Europe ;) -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal: Disable SSLv3 in Firefox ESR 31
- Original Message - From: Julien Pierre julien.pie...@oracle.com To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Tuesday, 21 October, 2014 1:59:44 AM Subject: Re: Proposal: Disable SSLv3 in Firefox ESR 31 Kai, On 10/20/2014 16:47, Kai Engert wrote: On Mon, 2014-10-20 at 16:45 -0700, Julien Pierre wrote: What is the purpose of Firefox continuing to do any fallback at all ? IMO, making a second connection with any lower version of SSL/TLS defeats the intent of the SSL/TLS protocol, which have built-in defenses against protocol version downgrade. Isn't it time this fallback gets eliminated at last ? I'm stating what I found, I'm not making that decision. Sorry, I didn't mean to blame you for that decision - but IMO this should be pointed out to whoever made that call. The whole TLS_FALLBACK_SCSV would be unnecessary if not for this browser misbehavior - and I hope the IETF will reject it. Yes, it's external to the TLS, and yes, it's bad that browsers do use the manual fallback. Yes, the servers should be regularly updated and as such bugs that cause it fixed. Yes, the configurations should be updated to align them with current recommendations. But it doesn't happen in real world. So either we can push for policies which will never be implemented and be workable in real world, or we can try to make the systems secure in real world for people that care (both users and server admins that do apply updates regularly). Yes, I'd like to live in a world where it's not necessary, but we don't. -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Updates to the Server Side TLS guide
So I went over the https://wiki.mozilla.org/Security/Server_Side_TLS article with a bit more attention to detail and I think we should extend it in few places. Especially if it is supposed to be also the general recommendation for servers, not just for ones that are part of Mozilla network. 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) * negotiation of curves in ECDHE - servers in general should be able to negotiate the used curve for this KEX - it's a RFC MUST * 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) * 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 * 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) * 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 * intolerance of TLS1.3 ClientHello - new version is incoming while a significant percentage of servers can't do TLS version negotiation properly 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. 1 - https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/ -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: An error occurred during a connection to 9.183.191.164. Issuer certificate is invalid. (Error code: sec_error_ca_cert_invalid)
- Original Message - From: Peter Thornemann thornemann.pe...@gmail.com To: mozilla-dev-tech-cry...@lists.mozilla.org Sent: Monday, 22 September, 2014 10:05:42 AM Subject: An error occurred during a connection to 9.183.191.164. Issuer certificate is invalid. (Error code: sec_error_ca_cert_invalid) My work have upgrade from FF 24.0 to FF 31.1.0 on both Linux Redhat 6 and windows 7. On FF 31.1.0 we now get this error when we try to access this adress An error occurred during a connection to 9.183.191.164. Issuer certificate is invalid. (Error code: sec_error_ca_cert_invalid) from Linux But from Windows it work fine This is not externally reachable. Could you connect to it using openssl s_client -showcerts -connect 9.183.191.164:443 and attach full output? There were few changes that could have caused it. -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
- Original Message - From: Brian Smith br...@briansmith.org To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Cc: mozilla-dev-tech-cry...@lists.mozilla.org Sent: Thursday, 10 July, 2014 9:41:43 PM Subject: Re: Road to RC4-free web (the case for YouTube without RC4) On Thu, Jul 10, 2014 at 5:00 AM, Hubert Kario hka...@redhat.com wrote: - Original Message - From: Brian Smith br...@briansmith.org snip However, it is likely that crypto libraries that make the two changes above will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too. So, I hope that they also enable TLS_ECDHE_*_WITH_AES_*_GCM at the same time they deploy these changes. snip What basis do you have to assume that server administrators will actually upgrade their Apache/nginx/lighttpd/OpenSSL/etc. installations? In this thread you pointed out that a number of websites had updated their servers to add TLS_RSA_WITH_AES*_GCM* and disable TLS_RSA_WITH_*_CBC_*, so that Firefox now only negotiates RC4 with them when it could be negotiating AES-GCM. The fact that they updated their servers to add non-ECDHE AES-GCM support is good evidence that these server administrators are paying attention and are likely to update if/when their server software vendor gives it to them if it solves a need (like improving what Firefox negotiates), right? The non-ECDHE AES-GCM is just youtube (which is the thorn in my side). ECDHE with non-AES-GCM (but with SHA256) is 2% of Internet. Those connections could use AES instead of RC4 (and actually increase % of sites that negotiate PFS ssuites), with no change other than addition of single cipher suite to Firefox: ECDHE-RSA-AES128-SHA256. But I want to add those additional ciphers so that: * I can watch youtube with RC4 less Firefox * others (when using the extension/settings) have maximum interoperability after disabling RC4 Regarding your request about how to write the addon: I don't have time to work on that addon, but I know it is possible to write it. I appreciate the gesture, but I'm asking for pointers to documentation or other addons that do something similar so that I could write it. -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
- Original Message - From: Brian Smith br...@briansmith.org To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Thursday, 10 July, 2014 3:02:34 AM Subject: Re: Road to RC4-free web (the case for YouTube without RC4) On Wed, Jul 2, 2014 at 5:08 AM, Hubert Kario hka...@redhat.com wrote: Also, see Gavin's email here about adding such prefs in general. He basically says, Don't do it. Note that Gavin is the Firefox module owner: https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ As Benjamin notes, an add-on is a much better way to suggest people customize these things, and writing an add-on that sets a pref is trivial. So you'd accept code that is able to change this preference but doesn't expose it through about:config? I'm more that willing to create such patchset and extension pair. It is already possible to write such an extension without any new Firefox APIs, because extensions can call NSS functions. Can you point me in the direction of how to do that? Also, won't it require native code? -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
- Original Message - From: Brian Smith br...@briansmith.org To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Cc: mozilla-dev-tech-cry...@lists.mozilla.org Sent: Thursday, 10 July, 2014 2:40:55 AM Subject: Re: Road to RC4-free web (the case for YouTube without RC4) On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre julien.pie...@oracle.com wrote: On 7/1/2014 14:05, Brian Smith wrote: I think, in parallel with that, we can figure out why so many sites are still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and start the technical evangelism efforts to help them. Cheers, Brian The reason for sites choosing RC4 over AES_CBC might be due to the various vulnerabilities against CBC mode, at least for sites that support TLS 1.0 . I think a more useful form of evangelism would be to get sites to stop accepting SSL 3.0 and TLS 1.0 protocols. Servers that cannot, for whatever reason, support the AES-GCM cipher suites, should be changed to prefer AES-CBC cipher suites over RC4-based cipher suites at least for TLS 1.1 and later. Most sites are not going to stop accepting SSL 3.0 and/or TLS 1.0 any time soon, because they want to be compatible with Internet Explorer on Windows XP and other software that doesn't support TLS 1.1+. However, in the IETF, there is an effort, spearheaded by our friends at Google, for solving the downgrade problem: http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 This simple feature, if implemented by the browser and by the server, allows the server to recognize that the browser has tried a non-secure downgrade to a lower version of TLS. Once the server recognizes that, the server can reject the downgraded connection. The net effect is that, assuming modern browsers quickly add support for this mechanism, the server can be ensure that it only uses CBC cipher suites with modern browsers over TLS 1.1 or later and that it never uses RC4-based cipher suites with modern browsers (in conjunction with the prefer AES-CBC cipher suites over RC4 cipher suites change I suggest above). However, it is likely that crypto libraries that make the two changes above will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too. So, I hope that they also enable TLS_ECDHE_*_WITH_AES_*_GCM at the same time they deploy these changes. FWIW, I filed bugs [1][2] for adding support for draft-ietf-tls-downgrade-scsv-00 to NSS, Gecko, and Firefox. What basis do you have to assume that server administrators will actually upgrade their Apache/nginx/lighttpd/OpenSSL/etc. installations? There are many installation that still haven't fixed their servers after Heartbleed (0.5%) or the CCS vulnerability (9%)[1]! Over 1% of servers still support SSL3 only[2]! 1 - https://www.trustworthyinternet.org/ssl-pulse/ 2 - http://wp.me/p4BPwe-x -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
- Original Message - From: Kurt Roeckx k...@roeckx.be To: mozilla-dev-tech-cry...@lists.mozilla.org Sent: Monday, 30 June, 2014 10:56:13 AM Subject: Re: Road to RC4-free web (the case for YouTube without RC4) On 2014-06-30 02:35, Hubert Kario wrote: The benefits of ECDHE outweigh the risks of using RC4, I have to disagree here. Even 1024 bit DHE requires a targeted attack at ~80 bit complexity. Currently we see RC4 at around 56 bit, with a completely unoptimized attack... Do you have a reference for those 56 bit? My estimation. http://www.isg.rhul.ac.uk/tls/ requires 2^30 sessions with 2^8 computations to recover full text. And it requires 2^24 sessions and 2^8 computations to recover some bytes. I assumed two to one data-to-computation equivalence and added 8 bits from the original attack. Even if the equivalence is higher, capturing 2^10 of sessions won't require extended monitoring. If we then say that this then requires 2^67 computations (over 3 to 1 equivalence) the cost of that is around $25 using EC2. That's mafia kind of money, not NSA. I trust RC4 as much as single DES - good against script kiddies. I think we should do all that's possible to avoid RC4. I think that for now we should follow Microsoft in not having RC4 in the initial handshake and if fails retry with RC4 enabled. yes, that would certainly help It's my understanding that that should reduce RC4 usage from 20% of the sites to 1%. that's correct -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Road to RC4-free web (the case for YouTube without RC4)
- Original Message - From: Brian Smith br...@briansmith.org To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Monday, 30 June, 2014 12:23:41 AM Subject: Re: Road to RC4-free web (the case for YouTube without RC4) On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario hka...@redhat.com wrote: Because of that, disabling RC4 should be possible for many users. The big exception for that was YouTube video servers[4] which only recently gained support for TLS_RSA_WITH_AES_128_GCM_SHA256. Hi, I read your blog post at http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less, which is interesting. The blog post compares how enabling/disabling various cipher suites affects the percentage of sites that end up negotiating RC4. However, I noticed that you didn't measure how enabling/disabling various cipher suites affects how often Firefox uses ECDHE, DHE with a strong (=1280 bit, at least), DHE with weak, or RSA key exchange. If the question is, does removing RC4 with adding extra ciphers gives up PFS?, the answer is likely* yes, by 2%. But adding or removing ciphers has small impact on PFS compared to the 20% elephant in the room. * - those are simulated handshakes using OpenSSL cipher order, so while AES to RC4 relation is maintained, the relation between AES128 and AES256 is not as well as relation between DHE-AES128 and AES256, so in reality connection using Firefox would likely end up with AES128 cipher while the below order shows AES256 ciphers. Next month's data will include information if the server appears to use server cipher order or not so the simulations will match reality more closely. If we use following cipher order: 'ECDHE-ECDSA-AES128-GCM-SHA256', 'ECDHE-RSA-AES128-GCM-SHA256', 'ECDHE-ECDSA-AES256-SHA', 'ECDHE-ECDSA-AES128-SHA', 'ECDHE-RSA-AES128-SHA', 'ECDHE-RSA-AES256-SHA', 'ECDHE-RSA-DES-CBC3-SHA', 'ECDHE-ECDSA-RC4-SHA', 'ECDHE-RSA-RC4-SHA', 'DHE-RSA-AES128-SHA', 'DHE-DSS-AES128-SHA', 'DHE-RSA-CAMELLIA128-SHA', 'DHE-RSA-AES256-SHA', 'DHE-DSS-AES256-SHA', 'DHE-RSA-CAMELLIA256-SHA', 'EDH-RSA-DES-CBC3-SHA', 'AES128-SHA', 'CAMELLIA128-SHA', 'AES256-SHA', 'CAMELLIA256-SHA', 'DES-CBC3-SHA', 'RC4-SHA', 'RC4-MD5' Then simulated handshakes end with: Selected ciphers CountPercent -+-+-- AES128-SHA 23354 6.6545 AES256-SHA 48262 13.7519 CAMELLIA128-SHA2 0.0006 CAMELLIA256-SHA188 0.0536 DES-CBC3-SHA 996 0.2838 DHE-RSA-AES128-SHA 704 0.2006 DHE-RSA-AES256-SHA 10581930.1522 DHE-RSA-CAMELLIA256-SHA336 0.0957 ECDHE-ECDSA-AES128-GCM-SHA256 9192 2.6192 ECDHE-ECDSA-AES128-SHA 120.0034 ECDHE-ECDSA-RC4-SHA1 0.0003 ECDHE-RSA-AES128-GCM-SHA25640876 11.6473 ECDHE-RSA-AES128-SHA 172 0.049 ECDHE-RSA-AES256-SHA 45331 12.9167 ECDHE-RSA-DES-CBC3-SHA 252 0.0718 ECDHE-RSA-RC4-SHA 27726 7.9003 EDH-RSA-DES-CBC3-SHA 652 0.1858 RC4-MD59344 2.6625 RC4-SHA37699 10.742 x:DHE 10751130.6344 x:ECDHE12356235.208 x:kRSA 11984534.1488 Removing 'ECDHE-ECDSA-RC4-SHA', 'ECDHE-RSA-RC4-SHA', Doesn't change the compatibility: x:FF 29 incompatible 390.0111 causes the servers to select following ciphers: Selected ciphers CountPercent -+-+-- AES128-SHA 23354 6.6545 AES256-SHA 48262 13.7519 CAMELLIA128-SHA2 0.0006 CAMELLIA256-SHA188 0.0536 DES-CBC3-SHA 996 0.2838 DHE-RSA-AES128-SHA 704 0.2006 DHE-RSA-AES256-SHA 10582130.1528 DHE-RSA-CAMELLIA256-SHA336 0.0957 ECDHE-ECDSA-AES128-GCM-SHA256 9192 2.6192 ECDHE-ECDSA-AES128-SHA 130.0037 ECDHE-RSA-AES128-GCM-SHA25640878 11.6478 ECDHE-RSA-AES128-SHA 200 0.057 ECDHE-RSA-AES256-SHA 46972 13.3843 ECDHE-RSA-DES-CBC3-SHA 252 0.0718 EDH-RSA-DES-CBC3-SHA 652 0.1858 RC4-MD59344 2.6625 RC4-SHA63744 18.1633 x:DHE 10751330.6349 x:ECDHE97507 27.7838 x:kRSA 14589041.5701 So about 0.5% servers did select better cipher, mostly ECDHE-RSA-AES256-SHA
Road to RC4-free web (the case for YouTube without RC4)
The number of sites that prefer RC4 while still supporting other ciphers are very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not changing much. The percent of servers that support only RC4 is steadily dropping (1.771% in April[3], 1.194% in May[2], 0.985% in June[1]). Because of that, disabling RC4 should be possible for many users. The big exception for that was YouTube video servers[4] which only recently gained support for TLS_RSA_WITH_AES_128_GCM_SHA256. So let me be blunt. Why we can't have[5] a setting that will allow users of over 2% of servers increase their security[6] and make youtube usable for people that disabled RC4[7,8,9]. While we have a setting like security.ssl3.rsa_seed_sha which as far as I can see affects no servers[6]? Note that I'm not talking about changing the default configuration, I'm talking only about adding optional functionality. Full analisys is available here: http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less 1 - http://securitypitfalls.wordpress.com/2014/06/24/rc4-only 2 - http://securitypitfalls.wordpress.com/2014/06/24/may-2014 3 - http://securitypitfalls.wordpress.com/2014/05/07/cipher-scan 4 - https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-uxaxovg-5goz.googlevideo. com 5 - https://bugzilla.mozilla.org/show_bug.cgi?id=1029179 6 - http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less 7 - https://github.com/klemens/ff-youtube-all-html5/issues/24 8 - https://support.mozilla.org/en-US/questions/990082 9 - https://productforums.google.com/forum/#!searchin/youtube/rc4/youtube/ VuVshylMDO0/EMuBNFmgQLwJ -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
