Hi all,
I propose we remove the "Revocation Lists" feature (Options -> Advanced ->
Revocation Lists). Are there any objections? If so, please explain your
objection.
A certificate revocation list (CRL) is a list of revoked certificates,
published by the certificate authority that issued the ce
Sean Leonard wrote:
> Brian Smith wrote:
> > The "Revocation Lists" feature allows a user to configure Firefox
> > to poll the CAs server on a regular interval. As far as I know,
> > Firefox is the only browser to have such a feature. Other browser
> > eith
Robert Relyea wrote:
> Brian, I was under the impression you wanted to remove the CRL
> autofetching feature (where you enter a URL and a fetching time and
> the CRL will automatically be fetched). When I looked at the UI, it
> looked like it had both the URL fetching feature as well as the
> abili
Robert Relyea wrote:
> Oh, in that case I can say we have customers that definately need to
> use CRLs that have been loaded and stored in the database.
> > To be clear, I don't know of any reason to consider the processing
> > of already-loaded CRLs as a requirement for Firefox.
> Oh, then I'd s
Robert Relyea wrote:
> On 05/02/2013 02:02 PM, Brian Smith wrote:
> So are you actually going to ship a different version of NSS with the
> default Firefox, or are you going to create a switch that changes the
> behavior of NSS with respect to stored CRLs (and what about cached
> C
Julien Pierre wrote:
> If this is about removing the feature from NSS altogether on the
> other hand, I would like to state that we have several several
> products at Oracle that use NSS and rely on the ability to have
> CRLs stored in the database, and processed during certificate
> validation.
I
See
https://mxr.mozilla.org/mozilla-central/source/services/crypto/modules/WeaveCrypto.js#123
and https://bugzilla.mozilla.org/show_bug.cgi?id=583209
and https://bugzilla.mozilla.org/show_bug.cgi?id=648407
On Tue, Jul 30, 2013 at 11:58 PM, hv wrote:
> Hi,
>
> I was not able to open NSS on FF
On Wed, Jul 31, 2013 at 1:58 AM, Robert Relyea wrote:
> On 07/30/2013 04:27 PM, Brian Smith wrote:
>
>> See
>> https://mxr.mozilla.org/**mozilla-central/source/**
>> services/crypto/modules/**WeaveCrypto.js#123<https://mxr.mozilla.org/mozilla-central/source/services/cr
Please see https://briansmith.org/browser-ciphersuites-01.html
First, this is a proposal to change the set of sequence of ciphersuites
that Firefox offers. Secondly, this is an invitation for other browser
makers to adopt the same sequence of ciphersuites to maximize
interoperability, to minimize
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham wrote:
> * Can you provide some background or references on exactly how
> ciphersuite construction and choice works? Can I invent e.g.
> TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of
> elements? Can any combination be encoded in
On Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson wrote:
> I believe this plan would have poor side effects. For example, if Apple
> ships clients with a broken ECDSA implementation [0], a server cannot
> detect detect if a connecting client is an Apple product and avoid the use
> of ECDSA in th
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco wrote:
> Hello Brian
>
> I think this proposal has 3 sections.
> 1. Unifing SSL behavior on browsers.
> 2. Altering the criteria for cipher suite selection in Firefox (actually
> NSS)
> 3. removing certain cipher suites from the default firefox ciph
On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang wrote:
> On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling
> wrote:
> >
> > Wan-Teh, why do you think Firefox should specify a preference for ECDSA
> over
> > RSA?
>
> Because ECDSA is more secure than RSA, and ECC implementations will
> become faster
On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham wrote:
> On 09/08/13 18:12, Brian Smith wrote:
> > No, each combination is hard-coded into its own distinct code point that
> is
> > registered with IANA:
> >
> https://www.iana.org/assignments/tls-parameters/tls-parame
On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea wrote:
> So looking at this list, I think we have a major inconsistency.
>
> We put Ephemeral over non-ephemeral, but we put 128 over 256.
>
> While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think
> in doing so we are taking a much
On Mon, Aug 26, 2013 at 2:24 PM, Brian Smith wrote:
> Something to note is that MSIE has always put AES-128 cipher suites ahead
> of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS
> cipher suites, though.
>
>
I meant: MSIE has always put AES-128 cipher suites
On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto
wrote:
>
> While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for
> client signning, signText and are needed.
> Also things like Handling smart card events or Loading PKCS #11
> modules is being use by many.
> So, you _CANT_ rem
On Fri, Sep 27, 2013 at 2:31 AM, Eddy Nigg wrote:
> On 09/27/2013 02:29 AM, From Brian Smith:
>
>> I have met with several members of our DOM and web API teams and we've
>> tentatively agreed that we should remove these functions if at all
>> possible--as soon as 201
On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard wrote:
> On 9/27/2013 5:51 PM, Robert Relyea wrote:
>>
>> I don't have a problem with going for an industry standard way of doing
>> all of these things, but it's certainly pretty presumptuous to remove these
>> features without supplying the industry
sst...@mozilla.com wrote:
> Do we have telemetry on how frequently these APIs are used?
I expect that, of the small percentage of people that are using these APIs,
they are using them (except signText) very infrequently--like once a year. When
I talked to Ehsan and Andrew Overholt about this, we
On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann
wrote:
> Hi,
>
> AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2
> has been turned off at least 2 years ago. By removing SSL2 code we get :
>
> Smaller librarie
> faster compile time + test time
>
> What do you
Mountie Lee wrote:
> SEED was adopted to encourage escaping ActiveX dependency in Korea
> e-commerce environment.
Many people at Mozilla, including us platform engineers, want this
too. Our goal is to get rid of plugins on the internet completely.
And, also, personally I think it is a great idea
On Wed, Oct 2, 2013 at 2:28 AM, Mountie Lee wrote:
> Hi.
> currently SHA2 hash algorithm is used in TLS1.1 and 1.2
> mozilla firefox is supporting it now.
Hi,
Are you referring to the TLS_*_SHA256 cipher suites, or something
else? I believe that we support SHA256-based signatures everywhere
alre
On Mon, Oct 7, 2013 at 3:20 PM, Robert Relyea wrote:
> On 10/07/2013 12:44 PM, Wan-Teh Chang wrote:
>> On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith wrote:
>>> I think it is likely that some vendors of NSS-based products with very
>>> conservative backward-compatibil
On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent wrote:
> It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of
> AES-NI, or the CPU family.
> The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is
> probably fast enough for any browser
> If perform
On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee wrote:
> SHA2 hash required in e-commerce transaction by the korean regulation.
> and which is also used in TLSv1.1+.
Hi,
First, we will be enabling TLS 1.2 in Firefox very soon.
But, I think you may be referring to SHA-2-based cipher suites
proposed
On Fri, Nov 1, 2013 at 1:28 AM, Jeff Hodges wrote:
> /* New non-experimental openly spec'ed versions of those cipher suites. */
> #define SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 0xfeff
> #define SSL_RSA_FIPS_WITH_DES_CBC_SHA 0xfefe
>
> Does anyone know what spec this cipher suite came from?
Kai just tagged NSS_3_15_4_BETA1 yesterday but mozilla-central
urgently needs the fix for bug 934378 which is fixed by the patch for
NSS bug 935847, so I created the BETA2 tag which contains that fix.
Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
--
dev-tech-crypto mailing
On Fri, Nov 1, 2013 at 2:22 AM, Kurt Roeckx wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
>> On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
>> > So what needs to happen so that we can move on with this?
>>
>> I still have the same question. Nothing seems to b
On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx wrote:
> On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote:
>> Last week, I also learned that ENISA, a European standards group,
>> recommends Camellia alongside AES as a future-proof symmetric cipher
>> algorithm; see [4
On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx wrote:
> On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote:
>> On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith wrote:
>> >
>> > Also, AES implementations are highly optimized, well-audited,
>> > well-te
Hi all,
Please join me in welcoming David Keeler as a PSM peer! Amongst many
other things, David implemented the HSTS preload list, integrated OCSP
stapling into Firefox, and is current implementing the OCSP
Must-Staple feature, which is a key part of our goal of making
certificate status checking
On Fri, Dec 13, 2013 at 10:48 PM, wrote:
> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.
Hi,
Thank you
On Fri, Dec 13, 2013 at 11:51 PM, Brian Smith wrote:
> I will comment on your proposal again later. However, I want to share with
> you some usage data from Firefox 28 Beta, that I think we will find helpful
> in understanding what servers do. These numbers represent the cipher suite
&g
On Fri, Dec 13, 2013 at 10:48 PM, wrote:
> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.
>
> I have read
On Sat, Dec 14, 2013 at 2:13 PM, falcon wrote:
> I believe startssl (even) will sign ecdsa certs if you send a csr for one,
> but this is of little utility without an ecdsa trust anchor.
>
> Original message
> From: cl...@jhcloos.com
>
> Brian Smith wri
On Sat, Dec 14, 2013 at 3:51 PM, Kurt Roeckx wrote:
> On Sat, Dec 14, 2013 at 03:36:44PM -0800, Brian Smith wrote:
> >
> > Note that the cipher suites above were not agreed to in the previous
> > discussion and were not part of my proposal linked to above. They have
> bee
On Sat, Dec 14, 2013 at 4:47 PM, Kosuke Kaizuka wrote:
> > little supported, never negotiated cipher
>
> One of the largest websites which support Camellia is Yahoo!.
> Firefox 26 or lower use TLS_RSA_WITH_CAMELLIA_256_CBC_SHA with Yahoo!.
>
In Firefox 27 or later, Yahoo! will choose TLS_RSA_WIT
Kurt,
Thanks for your suggestions.
On Sat, Dec 14, 2013 at 12:46 PM, Kurt Roeckx wrote:
> I think we need to come up with a plan to improve security in the
> long run. I think what we would like to see in general is:
> - Only SHA256 or better (and so TLS 1.2)
>
This is gated almost purely on
On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx wrote:
> But some people are also considering disabling it by default,
> as I think all other where talking in this thread, not just
> reduce the preference.
>
> > For the same reason, the server ciphersuite that we recommend at
> > https://wiki.mozill
On Mon, Jan 27, 2014 at 9:26 AM, wrote:
> On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote:
> 2) NIST is a US government standards board that drives a lot of compliance
> regulation. There are companies what will want to be able show that they
> are NIST compliant. The
On Mon, Jan 27, 2014 at 10:49 AM, wrote:
> On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote:
>> On Mon, Jan 27, 2014 at 9:26 AM, wrote:
>
> I can't speak for FF - and I've certainly read enough standards to say
> that there are too many standards. I
On Mon, Jan 27, 2014 at 2:22 PM, 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.
>
On Wed, Jan 29, 2014 at 2:57 PM, wrote:
> I retried with a new ff profile and now it works, but only if I go
> directly to https://wayfarer.timewarnercable.com/; I cannot convince
> the new profile to let me in to the authenticated site for some reason
> I haven't diagnosed. That is probably why
On Wed, Feb 5, 2014 at 5:39 PM, wrote:
> Is the retry logic in nss or in mozilla-central? And if the latter,
> can anyone help narrow the search? I didn't find anything relevant
> in comm-central.
It is in mozilla-central, in
security/manager/ssl/src/nsNSSIOLayer.cpp. See these bugs:
https://b
On Wed, Feb 5, 2014 at 9:54 PM, Rasj wrote:
> Where are others? For example:
> TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
See https://briansmith.org/browser-ciphersuites-01.html. Also, please
look at the archives of this mailing list. There have been several
DOZEN of emails about the cipher suite sel
On Thu, Feb 13, 2014 at 9:57 AM, WebDoctor wrote:
>> > Should I write my own XPCOM object, or is there any other reasonable
>> > solution for that?. And can any one collaborate with me create this
>> > solution ?
> Thank you, i'll try to test the verifyCertNow in my extension and see what
>
On Tue, Mar 11, 2014 at 3:20 AM, Hanno Böck wrote:
> I wanted to bring up an issue regarding OCSP stapling.
> I filled this bug shortly after Firefox 27 came out:
> https://bugzilla.mozilla.org/show_bug.cgi?id=972304
>
> Short conclusion: If you have enabled OCSP stapling on your server this
> wi
[+dev-tech-crypto; Please discuss technical details of mozilla::pkix on
dev-tech-crypto and save dev-security-policy for discussion about Mozilla's
CA inclusion policies. There has been and will be a lot of technical
discussion on the behavior differences and rationale for those
differences--e.g. w
On Mon, Apr 28, 2014 at 4:29 PM, Erwann Abalea wrote:
> I know DER tools is only a decoder, and from
> https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp#921the
> construction of the request makes heavy use of hex magic to build a
> request.
>
Right. OCSP requests are
On Mon, Apr 28, 2014 at 4:45 PM, Erwann Abalea wrote:
> The chain builder can test all possible issuers until it finds a valid one
> (that's what OpenSSL does, for example). The AKI is only here to say
> "pssst, this is most probably the certificate you should try first".
>
Right. We need to mea
On Fri, Jun 27, 2014 at 9:19 AM, David Keeler wrote:
> On 06/27/2014 07:37 AM, Nathan Kinder wrote:
> > On 06/27/2014 12:13 AM, Frederik Braun wrote:
> >> To be frank, I have only ever seen the non-standard crypto functions
> >> used in attacks, rather than in purposeful use.
> >
> > That doesn't
On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario 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://sec
On Sun, Jun 29, 2014 at 5:35 PM, Hubert Kario wrote:
>
> > As I noted in my bug comment [1], I think that the rhetoric of us not
> > adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
> > ones, is significant. Software engineers at multiple companies referenced
> > our positio
On Mon, Jun 30, 2014 at 1:56 AM, Kurt Roeckx wrote:
> 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
On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre
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 ev
On Wed, Jul 2, 2014 at 5:28 AM, Hubert Kario 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
On Wed, Jul 2, 2014 at 5:08 AM, Hubert Kario 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 B
On Thu, Jul 10, 2014 at 4:53 AM, Henri Sivonen wrote:
> On Tue, Jul 1, 2014 at 11:58 PM, Brian Smith wrote:
> > I am interested in discussing what we can do to help more server side
> > products get better cipher suites by default, and on deciding whether we
> > add support
On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx wrote:
>
> [snip]
> An other alternative is using curve25519. It's also not standardized yet,
> but at this time it seems more likely to be standardized first.
Thanks for bringing up curve25519. I'd like to share a recent paper
written by Daniel J. B
On Thu, Jul 10, 2014 at 5:00 AM, Hubert Kario wrote:
> - Original Message -
>> From: "Brian Smith"
>> 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 to
Hi,
Amogst other things, PSM is the part of Gecko (Firefox) that connects
Gecko to NSS and other crypto bits.
David Keeler has taken on most of the responsibility for keeping
things in PSM running smoothly and so it makes sense to have him be
the module owner. After asking the other PSM module pe
On Tue, Aug 5, 2014 at 9:51 AM, wrote:
> Since updating to 31, I have not been able to log into a self signed web page:
>
> Secure Connection Failed
>
> An error occurred during a connection to taiserver:444. Certificate key usage
> inadequate for attempted operation. (Error code:
> sec_error_i
On Thu, Oct 2, 2014 at 9:03 AM, wrote:
> Maybe there is something that can be done to hep this situation? Maybe these
> old "private" certificates need to be cleaned out on upgrade? Or maybe
> something in the code that is going nuts trying to validate these "private"
> certificates needs to b
On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario 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.7
On Mon, Nov 10, 2014 at 6:51 PM, Nicholas Nethercote
wrote:
> I've been doing some heap allocation profiling and found that during
> basic usage NSS accounts for 1/3 of all of Firefox's cumulative (*not*
> live) heap allocations. We're talking gigabytes of allocations in
> short browsing sessions.
On Mon, Nov 10, 2014 at 9:04 PM, Nicholas Nethercote
wrote:
>> In your analysis, it would be better to use a call stack trace depth
>> larger than 5 that allows us to see what non-NSS function is calling
>> into NSS.
>
> I've attached to the bug a profile that uses a stack trace depth of 10.
Unfo
[+antoine]
Hanno Böck wrote:
> Unfortunately the code never got fully merged. Right now the state is
> that code for the basic functions exists in freebl, but all upper layer
> code is not merged.
There are multiple "upper layers" and, depending on your goals, some
should be prioritized higher t
Ryan Sleevi wrote:
> - It assumes all the parameters can be expressed via a SECOidTag. That
> is, it's missing hash alg, mgf alg, salt length (e.g. the
> RSASSA-PSS-params construction)
I believe there are only a small number of (hashAlgorithm, mgf alg,
salt length) combinations that need to be
Hanno Böck wrote:
> Brian Smith wrote:
> Having new oids with sane pre-defined parameters would vastly simplify
> things. Back when I wrote that code I thought changing the standard is
> harder than implementing the non-optimal spec, but I might've been
> wrong.
To clarify:
Ryan Sleevi wrote:
> On Mon, March 16, 2015 1:06 pm, Erwann Abalea wrote:
>>
>> Phase RSA1024 out? I vote for it. Where's the ballot? :)
>
> This is a browser-side change. No ballot required (the only issue *should*
> be non-BR compliant certificates issued before the BR effective date)
>
> https
Rob Stradling wrote:
> The README [1] says:
> "If multiple certificate chains are found, the shortest one is used."
>
> That's a good strategy for a browser to employ when deciding which chain to
> show in its certificate viewer, but it's unlikely to be the best strategy
> when configuring a serve
Gervase Markham wrote:
> On 07/04/15 17:32, Hanno Böck wrote:
>> Are you using DSA? Firefox removed DSA recently (which is good - almost
>> nobody uses it and it's a quite fragile algorithm when it comes to
>> random numbers).
>
> Hanno's probably hit the nail on the head here.
> https://bugzilla.
On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas wrote:
> > On Apr 27, 2015, at 2:03 PM, Michael Peterson <
> michaelpeterson...@gmail.com> wrote:
> > Now, in the album I posted above (https://imgur.com/a/dmMdG), the last
> two screenshots show a packet capture from Wireshark. It appears that
> Firefox
David Woodhouse wrote:
> The sysadmin should be able to configure things for *all* users
> according to the desired policy, rather than forcing each user to set
> things up for themselves.
>
> And in turn the *developers* of the operating system distribution
> should be able to set a default poli
Julien Vehent wrote:
> 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 resis
Julien Vehent wrote:
> > The discussion above was biased in favor of what was best for FirefoxOS
> and
> > FxAndroid.
>
> AES-NI has also removed mosts concerns around bad implementations of
> AES, so it seems that the attacks we were concerned about two years ago
> do not apply anymore.
>
I thi
Zoogtfyz wrote:
> This is my recommendation for changes to the supported ciphersuits in
> Mozilla Firefox. I performed rigorous compatibility testing and everything
> works as advertized. I used Firefox telemetry data, SSL Pulse data, and my
> own tests to verify that *not a single* publicly acce
101 - 178 of 178 matches
Mail list logo
