gmane.comp.mozilla.security

Re: Get the finished message of TLS handshake

Wan-Teh Chang — 2013-05-14T19:50:33

On Tue, May 14, 2013 at 2:12 AM, Christian Koßmann
<christiankossmann< at >googlemail.com> wrote:

Hi,

You can try the NSS patches in
https://bugzilla.mozilla.org/show_bug.cgi?id=563276#c1
https://bugzilla.mozilla.org/show_bug.cgi?id=563276#c4

The two patches are independent attempts at an implementation,
so you only need one of the patches.

You can also try the SSL_ExportKeyingMaterial function:
http://mxr.mozilla.org/nss/ident?i=SSL_ExportKeyingMaterial

This implements RFC 5705, Keying Material Exporters for
Transport Layer Security (TLS). It is already in NSS.

Wan-Teh

Get the finished message of TLS handshake

Christian Koßmann — 2013-05-14T09:12:55

Hey,

I try to implement a prototype implementation of tls-unique (RFC 5929) in Firefox for a German research group. Therefore I need the finished message of the TLS handshake. After hours of research I found out that this is "most likely" not possible to get the finished message in a Firefox extension. But what about XPCOM components? Is it possible to create an XPCOM component that propagates such implementation details or do I really have to modify the source code of nss? Or is there any other way that I have overlooked?

I looking forward to your answer,
Christian Koßmann

Re: It's time to remove plugin support from Firefox mobile

Gervase Markham — 2013-05-13T13:06:14

.... and it's no longer available for new installations.


I think the first big question is: is driving people to using native
apps rather than Flash a win or a loss for us?

Clearly we'd prefer them to use HTML5 video, but they won't all do that.

The second big question is regard to user opinion. When we didn't have
Flash support we were regularly panned for it - even beyond the Flash
EOL announcement IIRC. Do we want to take the hit to our Market rating?

Addons are also an option.

How are addons a serious option?

Gerv

Re: Removal of "Revocation Lists" feature (Options -> Advanced ->Revocation Lists)

Michael Ströder — 2013-05-11T11:15:48

For privacy reasons many people switch off OCSP checking. And therefore I have
strong objections against everything which makes CRL checking less flexible.

Ciao, Michael.

It's time to remove plugin support from Firefox mobile

David Keeler — 2013-05-10T17:54:38

[bcc'd to many lists for wide visibility - discussion should probably be
on mobile.firefox.dev
(https://mail.mozilla.org/listinfo/mobile-firefox-dev )]

TL;DR: Now is a good time to remove plugin support from Firefox for Android.

Consider:
* We do not support plugins for Firefox OS and do not plan to
* The only plugin that most users care about is Flash. Adobe stopped
development for Flash on Android in November of 2011, which is a year
and a half ago[1].
* Popular sites that use plugins have native apps. This includes
YouTube, Netflix, Hulu, and so on. Other sites can follow suit or use
modern web technologies like HTML5. Addons are also an option.
* Plugins are a security hazard
* Plugins drain battery life and make Firefox seem slow

Let's be bold, let's protect our users, and let's move the web forward.

[1] http://blogs.adobe.com/conversations/2011/11/flash-focus.html

Re: Removal of "Revocation Lists" feature (Options -> Advanced ->Revocation Lists)

Julien Pierre — 2013-05-09T01:44:27

Brian,

If this is just about changing the UI in Firefox, I have no objection.

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. These 
applications act as both SSL servers and clients, and we expect the CRLs 
to be supported in both.

While some Oracle products are moving away from NSS, old versions 
continue to be supported and we are picking up new NSS releases to get 
certain security fixes. We couldn't do that anymore if the CRL feature 
went away. In the past, before Oracle, Sun went to great pains to work 
on the common public NSS tree for these products. We certainly don't 
want to fork NSS again at this stage.

Julien

On 4/30/2013 14:28, Brian Smith wrote:
 d" mechanism. However, I think that we can make this decision independently of that decision.

Re: Removal of "Revocation Lists" feature (Options -> Advanced ->Revocation Lists)

Jan Schejbal — 2013-05-01T21:48:22

Am 2013-04-30 23:28, schrieb Brian Smith:

I just checked. In my list, I had two CRLs, one by OpenLimit, one by
CACert. The CACert had autoupdate enabled and set to be done 1 day
before nextupdate date, a nextUpdate date in 2008, and no reported
update failures. Manually triggering the update did bring up a current
CRL. Therefor, I am not even sure if the feature works properly.

The only place where I could imagine this could be relevant are
enterprise setups where someone has rolled out their own CA, either for
https or for mail. Thus, I would suggest asking on the various
Enterprise Working Group mailing list.

Kind regards,
Jan

Re: OCSP Stapling w/ Delegated Signers

Rob Stradling — 2013-04-29T07:46:20

Tom, RFC2560 deals with this issue (see section 4.2.2.2.1).

Public CAs that use delegated OCSP signing should follow the CABForum 
Baseline Requirements (section 13.2.5):
   "the OCSP signing Certificate MUST contain an extension of type
    id-pkix-ocsp-nocheck, as defined by RFC2560."

Delegated OCSP signing certificates are end-entity certs, not 
Intermediate certs.

Re: OCSP Stapling w/ Delegated Signers

Kai Engert — 2013-04-27T19:18:20

On Sat, 2013-04-27 at 17:37 +0000, Tom Ritter wrote: 

See the definition of an OCSPResponse in RFC 2560.

An OCSPResponse may contain an optional sequence of additional
certificates. This is the place to transport the delegated signing cert.

In my understanding, if you request status for a certificate C1, which
was signed by a CA1, and the CA1 choses to use a delegated signing cert
C2, then both C1 and C2 must have been signed by the same CA1.

Although an OCSP response can contain only information related to one
CA, the signed data inside the OCSPResponse contains a sequence of one
or more entries of type SingleResponse. It guess this sequence could
contain status entries for both C1 and C2.

I wonder if an OCSP responder using a delegated signing cert should
always include status information for the delegated signing cert, too.

Kai

OCSP Stapling w/ Delegated Signers

Tom Ritter — 2013-04-27T17:37:42

I have what may be a well tread topic in the nuances of OCSP Stapling
- but after having it posed to me I realized I did not know the
answer.  Thus, I ask publicly in the hope that there is a simple
answer I can point to in the future.

If a CA uses a delegated signer for OCSP, and a website delivers an
OCSP Staple... How does the user (talking only to the website) get

 - The Delegated Signing Cert (which is presumably an Intermediate off
a Trust Root)
 - The revocation information for *that* Intermediate cert

thanks,
tom

Safebrowsing

fr0sty — 2013-04-22T15:53:32

Hi,
I have a few questions about the safebrowsing feature in Firefox.
Answering any of these questions would be extremely helpful.

1. How does one clear the safebrowsing data?
2. Does Firefox stop fetching safebrowsing data if the browser is
inactive? The spec says the list is updated every 30 minutes, but
doesn't say anything about user activity.
3. The data itself is authenticated, but it is also served over HTTP,
and the protocol supports requesting specific lists and segments. This
might introduce the ability of websites to repeatedly block list
segments in an attempt to create a "supercookie" in the client. This
"supercookie" looks like it can persist for up to 6 hours (based on
the retry behavior in
https://wiki.mozilla.org/Phishing_Protection:_Design_Documentation#Client_Backoff
<http://www.google.com/url?q=https%3A%2F%2Fwiki.mozilla.org%2FPhishing_Protection%3A_Design_Documentation%23Client_Backoff&sa=D&sntz=1&usg=AFQjCNER-Z-tD46-m2VihudZ4bBeqS9fpA>).
Is there a way for websites to read this supercookie at will? If so,
is there a way to prevent it/clear it?
4. Clearing the list data might also cause an immediate re-download of
all lists and segments. Does it?
5. Say I needed to clear the MAC key. How do I do that? Does doing so
invalidate the previous list data?

Again, any answers to these questions would be very helpful.

Thanks in advance,
cl34r

______________________________
____________________________________________
My GPG key:
http://pgp.jjim.de/pks/lookup?op=get&search=0x96B1D5FB69704B5E
<http://www.google.com/url?q=http%3A%2F%2Fpgp.jjim.de%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x96B1D5FB69704B5E&sa=D&sntz=1&usg=AFQjCNGYWYwKCgTZf-XYV-3QtL86W0M15Q>

Orangfuzz – an experimental user interaction fuzzer for Firefox OS

Gary Kwong — 2013-04-17T20:27:30

(followups to: mozilla.dev.b2g please)

I recently released an experimental user interaction (touch) fuzzer for 
Firefox OS, known as orangfuzz[1]. It is based on the Orangutan 
framework[2] by wlach.

More details can be found in a Mozilla Security blogpost[3].

Currently it only works with a Unagi B2G test device - I tested on a 
Geeksphone Keon but the Orangutan framework wasn't working as expected 
there yet.

Some possible ideas/ways to move forward:

* Decide on a common prepopulate state - currently orangfuzz always 
starts off on the homescreen, but ideally should be started from a 
fixed  state of Firefox with a fixed number of apps in a common position 
  (e.g. from reset) b2gpopulate[4] might help with this.
* Run the generated scripts with the long-running harness script[5] on 
pandaboards running B2G and orangutan, possibly via mozpool.
* Find ways to detect crashes - should we monitor 
"/data/b2g/mozilla/Crash\ Reports" for new crashes?
* Find a way to detect assertions - monitor logcat?
* Improve the reliability of reproducing testcases by another person - 
what are factors involved in one person not reproducing the crash by 
running the script on another similar device?
* Come up with a way to reduce testcases generated by the fuzzer 
automatically, maybe using Lithium[6].
* Come up with an optimum number of steps (currently 10000) such that we 
   achieve a fair balance of simulating sufficient user actions, not 
taking  too long for reduction, etc.
* How about less-obvious bugs which do not manifest as crashes or 
assertions, such as hangs / long gc pauses?

Also:

* There could also be an orangutan "action recorder" similar to 
Mozmill's Record function, thanks to Arky for this idea.
* Result generation reports could go somewhere, e.g. list of top crashes 
   found, or assertions, or Gaia errors. Maybe a tbpl-waterfall-style page?
* We could try to run this on an emulator for those without a phone, but 
we're not sure on the way forward here.
* Running on a special build of Gaia[7][8] with phone and messaging 
capabilities disabled (not yet well tested) is recommended for automated 
non-supervised runs, to avoid accidental dialing of emergency numbers.

More ideas/contributions welcome!

-Gary

[1] https://github.com/mozilla/orangfuzz
[2] https://github.com/wlach/orangutan
[3] 
https://blog.mozilla.org/security/2013/04/17/orangfuzz-an-experimental-user-interaction-fuzzer-for-firefox-os/
[4] https://github.com/mozilla/b2gpopulate
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=832328
[6] 
http://www.squarefree.com/2007/09/15/introducing-lithium-a-testcase-reduction-tool/
[7] https://github.com/gregorwagner/gaia/tree/monkey
[8] https://github.com/nth10sd/no-phone-no-messaging-gaia/tree/monkey

Re: Content Type Dependencies

Brian Smith — 2013-04-15T20:43:35

Yes, we should avoid adding new types that are subsets of anything except TYPE_OTHER.

IIRC, I am the one that wrote the "When adding new content types" comment and I enumerated the places that need to be updated *that I was aware of at the time*. I wrote that comment because I was surprised at all the places that need to be updated, but I did so from a position of extreme ignorance as I was very new to nsIContentPolicy at that time. I am not super confident in how comprehensive that list of places is, unfortunately. 

If you find a place that needs to be updated that I ommitted, please file a bug so that we can amend the documentation.

Cheers,
Brian

Re: Firefox behavior with CDPs and AIAs

Daniel Veditz — 2013-04-12T18:45:45

Which is why we don't support it.


yes, the biggie: even though CRLs are valid for a quite a while we don't 
cache them across restarts. Maybe not so bad if you never shut down your 
browser


Yes, note that CRL download support is only available as part of the 
not-yet-supported libpkix verification path. It's quite a bit bigger 
than just CRL downloads, this uses a completely different library to 
verify certificates. Libpkix is not entirely untested: Firefox uses it 
for EV certs, and Chrome uses it for everything. But last time I looked 
into it (months ago) there were bugs that were deemed bad enough that we 
weren't ready to turn it on in Firefox.


How does this interact with the security.ocsp.require pref? Do they 
conflict? Play well together? Or simply unrelated, one applying to the 
old path and one to libpkix?

-Dan Veditz

_______________________________________________
dev-security mailing list
dev-security< at >lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Firefox behavior with CDPs and AIAs

Daniel Veditz — 2013-04-12T18:34:36

Oh, sorry then. I looked before replying and didn't see it, guess it's 
an unreliable feed.

-Dan Veditz


_______________________________________________
dev-security mailing list
dev-security< at >lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Firefox behavior with CDPs and AIAs

2013-04-12T00:16:16

Thanks; I had already posted this to dev.tech.crypto...

Re: Firefox behavior with CDPs and AIAs

Camilo Viecco — 2013-04-12T00:12:25

It is possible (but not supported) to use have FF download the CRLs specified
by the certificate.

There are (of course) many caveats:

1. This is enabled by changing several hidden prefs (which mean we might change
them at any time without notifying our users).
2. Downloading is not the same as requiring fresh revocation information for all
connections.
3. If you require fresh revocation info you will have issues with certificates without
revocation information (such as self signed and business CAs) since they will be treated
as revoked and no override will be possible.
4. You will find some bugs on the certificate UI.
5. The code is not as tested as the rest of the FF and this is potentially more buggy.
6. There will be a non-trivial performance hit (specially network bases) as some CRLs
  are >500k and these entries are not cached across sessions (no peristent cache). This
  might not be an issue if you have good network connections (no mobile).

Without more due, here are the invocations to be added to your about:config. 
(not recomented for defaults for the reasons listed above.)

 bool pref: security.use_libpkix_verification: true  //enables alt verification lib
 bool pref: security.CRL_download.enabled: true      //enables crl download in libpkix only!
 bool pref: security.fresh_revocation_info.require : true // revocation info mandatory in libpkix only

Hope this helps

Camilo


----- Original Message -----
From: "Daniel Veditz" <dveditz< at >mozilla.com>
To: dev-security< at >lists.mozilla.org
Sent: Thursday, April 11, 2013 3:31:03 PM
Subject: Re: Firefox behavior with CDPs and AIAs

On 4/11/2013 1:26 PM, Rick Andrews wrote:

Sid was wrong :-) The guys who know the technical guts of our crypto 
implementation are over in m.d.tech.crypto

AFAIK we do not download CRLs based on certs, but will update CRLs the 
user has manually specified. We've talked about improving CRL handling 
as part of a comprehensive reform of revocation checking but have yet to 
solve the performance and space requirements of CRLs.

We do support OCSP and are in the process of adding support for OCSP 
stapling to improve performance, security, and privacy. Lack of an OCSP 
response is not fatal however, because in general OCSP has not been 
reliable enough for that. However, cautious users can change the mozilla 
pref security.OCSP.require to true if they wish the lack of an OCSP 
reponse to be fatal.

For anything more detailed (timelines, bug numbers) you'll need to go 
bug the .tech.crypto folks.

-Dan Veditz


_______________________________________________
dev-security mailing list
dev-security< at >lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Firefox behavior with CDPs and AIAs

Daniel Veditz — 2013-04-11T22:31:03

Sid was wrong :-) The guys who know the technical guts of our crypto 
implementation are over in m.d.tech.crypto

AFAIK we do not download CRLs based on certs, but will update CRLs the 
user has manually specified. We've talked about improving CRL handling 
as part of a comprehensive reform of revocation checking but have yet to 
solve the performance and space requirements of CRLs.

We do support OCSP and are in the process of adding support for OCSP 
stapling to improve performance, security, and privacy. Lack of an OCSP 
response is not fatal however, because in general OCSP has not been 
reliable enough for that. However, cautious users can change the mozilla 
pref security.OCSP.require to true if they wish the lack of an OCSP 
reponse to be fatal.

For anything more detailed (timelines, bug numbers) you'll need to go 
bug the .tech.crypto folks.

-Dan Veditz

_______________________________________________
dev-security mailing list
dev-security< at >lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

RE: Firefox behavior with CDPs and AIAs

Rick Andrews — 2013-04-11T20:26:01

Sid Stamm suggested dev.security...

Re: Firefox behavior with CDPs and AIAs

Ian Melven — 2013-04-11T20:22:28

you might also try asking this on mozilla.dev.tech.crypto :)

thanks,
ian

----- Original Message -----
From: "r andrews" <r.andrews< at >computer.org>
To: dev-security< at >lists.mozilla.org
Sent: Thursday, April 11, 2013 12:25:17 PM
Subject: Firefox behavior with CDPs and AIAs

I know that FF allows you to choose a CRL and it will check status against that CRL when it finds a cert issued by the CRL issuer. Does anyone know if FF uses the CDP in the cert or the cert's issuer name as a key to find the CRL?

The reason I ask is in regards to partitioned CRLs, where a CA could, for example, have one CRL for odd serial numbers and one for even. The CA would put the appropriate CDP in each cert, but would that confuse FF?

Same question about OCSP responses and AIA.

Does anyone know the answers for IE?
_______________________________________________
dev-security mailing list
dev-security< at >lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Firefox behavior with CDPs and AIAs

2013-04-11T19:25:17

I know that FF allows you to choose a CRL and it will check status against that CRL when it finds a cert issued by the CRL issuer. Does anyone know if FF uses the CDP in the cert or the cert's issuer name as a key to find the CRL?

The reason I ask is in regards to partitioned CRLs, where a CA could, for example, have one CRL for odd serial numbers and one for even. The CA would put the appropriate CDP in each cert, but would that confuse FF?

Same question about OCSP responses and AIA.

Does anyone know the answers for IE?