Re: DYMO Root CA installed by Label Printing Software

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>I similarly suspect you’re unaware of https://wicg.github.io/cors-rfc1918/ in
>which browsers seek to limit or restrict communication to such devices?

A... blog post?  Not sure what that is, it's labelled "A Collection of
Interesting Ideas", stashed on Github under the WICG's repository?  No, for
some inexplicable reason I seem to have missed that one.  Is there a "Beware
of the Leopard" sign somewhere?

It talks a lot about details of CORS, but I'm not sure what it says about
allowing secure HTTPS to devices at RFC 1918 addresses.  The doc says "we
propose a mitigation against these kinds of attacks that would require
internal devices to explicitly opt-in to requests from the public internet",
which indicates it's targeted at something altogether different.

>while also acknowledging that you have not kept up with the state of the
>industry for the past near-decade of improvements or enhancements

If the industry actually publicised some of this stuff rather than posting
articles with names like "A Collection of Interesting Ideas" to GitHub (which
in any case doesn't look like it actually addresses the problem) then I might
have kept up with it a bit more.  And as I've already pointed out, given the
number of vendors who are resorting to slipping in their own root CAs and
other tricks, I'm not the only one who's missing all these well-hidden
industry solutions.

>>  HTTPS to device with non-FQDN: ???
>>  HTTPS to device with static IP address: ???
>
>I suspect any answer such as “Don’t do this” or “This is intentionally not
>supported” will be met by you as “impractical”.

Try me.  The reason why I ruled out "negotiate a custom deal with a commercial
CA" is that it genuinely doesn't scale, you can't expect 10,000, 50,000,
100,000 (whatever the number is) device vendors to all cut a special deal with
a commercial/public/whatever CA just to allow a browser to talk to their $30
Internet-connected whatsit.

It's a simple enough question, so I'll repeat it again, a vendor selling some
sort of Internet-connected device that needs to be administered via HTTP (i.e.
using a browser), a printer, router, HVAC unit, whatever you like, wants to
add encryption to the connection.  How should they do this for the fairly
common scenarios of:

HTTPS to device on local network (e.g. RFC 1918).
HTTPS to device with non-FQDN.
HTTPS to device with static IP address.

What's the recommended BCP for a vendor to allow browser-based HTTPS access
for these scenarios?  I'm genuinely curious.  And please publish the
recommendation so others can follow it (not on GitHub labelled "A Collection
of Interesting Ideas").

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 10, 2018 at 3:33 AM Peter Gutmann 
wrote:

> Ryan Sleevi  writes:
>
> >I hope you can see how I responded to precisely the problem provided.
>
> You responded to that one specific limited instance.


I responded to the topic of this thread, with actionable advice for the
problem described and questioned posed, and with specific advice to
disregard the dangerous, insecure, and outdated advice you provided.


That doesn't work for
> anything else where you've got a service that you want to make available
> over
> HTTPS.  Native messaging is a hack to get around a problem with browsers,
> as
> soon as you move off the local machine it reappears again, which is what I
> was
> pointing out.


You continue to use pejoratives such as “hack” or “problem”, while also
acknowledging that you have not kept up with the state of the industry for
the past near-decade of improvements or enhancements. Perhaps it may be
more productive to listen and research before casting aspersions and
judgement - it would certainly be less alienating and dismissive.

Since this is something that keeps cropping up, and from all signs will keep
> on cropping up, perhaps the browser vendors could publish some sort of
> guide/BCP on how to do it right that everyone could follow.  For example:
>
>   HTTPS to localhost: Use Native Messaging
>   HTTPS to device on local network (e.g. RFC 1918): ???


I similarly suspect you’re unaware of https://wicg.github.io/cors-rfc1918/ in
which browsers seek to limit or restrict communication to such devices?

  HTTPS to device with non-FQDN: ???
>   HTTPS to device with static IP address: ???


I suspect any answer such as “Don’t do this” or “This is intentionally not
supported” will be met by you as “impractical”. That said, I don’t find it
particularly useful to engage in the shifting goalposts here, especially
not without specific use cases in mind. That’s because discussions of
“practical” will inevitably be used to arbitrarily reject solutions for
contrived examples, rather than offer meaningful discussion tailored to
real use cases and assessments of tradeoffs or approaches.

This would solve... well, at least take a step towards solving the same
> issue
> that keeps coming up again and again.  If there's a definitive answer,
> developers could refer to that and get it right.


Note these didn’t come up in this thread, not have they recently in the
Forum.

Oh, and saying "you need to negotiate a custom deal with a
> commercial/public/whatever-you-want-to-call-it CA" doesn't count as a
> solution, it has to be something that's actually practical.


By this definition, any solution short of hand holding / doing it for them
is “impractical”. Engineering has costs and tradeoffs. I get that you’re
not willing to entertain those is your pursuits, but please recognize the
danger when someone as respected within the community as you are offers
solutions that are substantially insecure because of this. It may be
better, in that case, to either disclose that there are tradeoffs you
personally would not make, or to simply not offer them forward as
solutions, certainly not best practices.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>I hope you can see how I responded to precisely the problem provided.

You responded to that one specific limited instance.  That doesn't work for
anything else where you've got a service that you want to make available over
HTTPS.  Native messaging is a hack to get around a problem with browsers, as
soon as you move off the local machine it reappears again, which is what I was
pointing out.

Since this is something that keeps cropping up, and from all signs will keep
on cropping up, perhaps the browser vendors could publish some sort of
guide/BCP on how to do it right that everyone could follow.  For example:

  HTTPS to localhost: Use Native Messaging
  HTTPS to device on local network (e.g. RFC 1918): ???
  HTTPS to device with non-FQDN: ???
  HTTPS to device with static IP address: ???

This would solve... well, at least take a step towards solving the same issue
that keeps coming up again and again.  If there's a definitive answer,
developers could refer to that and get it right.

Oh, and saying "you need to negotiate a custom deal with a
commercial/public/whatever-you-want-to-call-it CA" doesn't count as a
solution, it has to be something that's actually practical.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Potential problem with ACME TLS-SNI-01 validation

[josh--- via dev-security-policy]

We've received a credible report of a problem with ACME TLS-SNI-01 validation 
which could allow people to get certificates they should not be able to get. 
While we investigate further we have disabled tls-sni-01 validation.

We'll post more information soon.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 10, 2018 at 12:42 AM Peter Gutmann 
wrote:

> Ryan Sleevi  writes:
>
> >Of course, if that doesn’t tickle your fancy, there are other ways that
> are
> >supported that you may not have heard about - for example:
> >
> https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/native-messaging
> >
> >
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
> >
> >https://developer.chrome.com/apps/nativeMessaging
>
> So I've had a quick look at these and unless I've missed something they're
> just a means of talking to an app on your local machine.  As soon as you go
> outside that boundary, e.g. to configure a router or printer on your local
> network via a browser, you're back to having to add a new root CA to the
> cert
> store for it to work.  Or have I missed something?


I believe you may have missed the original message in your haste to decry
browsers and offer outdated anecdotes and dangerously insecure solutions
(the latter of which is the most troubling and frustrating part of this
exchange, and bears greater professional responsibility)

The use case and feature was:

“called "DYMO Root CA (for localhost)". This certificate was installed by
the label printing software, I installed for my DYMO Label Printer.

It is intended purpose is to allow web-based tools to send content to the
label printer to be printed by the local machine.”

I hope you can see how I responded to precisely the problem provided.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Jonathan Rudenberg via dev-security-policy]

> On Jan 9, 2018, at 19:31, Peter Gutmann via dev-security-policy 
>  wrote:
> 
> Jonathan Rudenberg  writes:
> 
>> For communicating with other machines, the correct thing to do is to issue a
>> unique certificate for each device from a publicly trusted CA. The way Plex
>> does this is a good example:
>> https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
> 
> But the Plex solution required DynDNS, partnering with a CA for custom hash-
> based wildcard certificates (and for which the CA had to create a new custom
> CA cert), and other tricks, I don't think that generalises.  In effect this
> has given Plex their own in-house CA (by proxy), which is a point solution for
> one vendor but not something that any vendor can build into a product.

There is nothing special about this, hardware vendors regularly do a similar 
amount of work around discovery/provisioning for their devices. Additionally, 
there is nothing special about the CA, it can be done with Let’s Encrypt! For 
example: https://crt.sh/?q=%25.myfritz.net

These types of use cases (“IOT”) are regularly brought up by CAs on mailing 
lists, so I assume there are several that are quite happy to help you set 
something similar up.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Peter Gutmann via dev-security-policy]

Jonathan Rudenberg  writes:

>For communicating with other machines, the correct thing to do is to issue a
>unique certificate for each device from a publicly trusted CA. The way Plex
>does this is a good example:
>https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

But the Plex solution required DynDNS, partnering with a CA for custom hash-
based wildcard certificates (and for which the CA had to create a new custom
CA cert), and other tricks, I don't think that generalises.  In effect this
has given Plex their own in-house CA (by proxy), which is a point solution for
one vendor but not something that any vendor can build into a product.

Anyone from Plex want to comment on how much effort was involved in this? It'd
be interesting to know what was required to negotiate this deal, and how long
it took, just as a reference point for anyone else considering it.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Changes to CA Program - Q1 2018

[Kathleen Wilson via dev-security-policy]

All,

I would like to thank Aaron Wu for all of his help on our CA Program, 
and am sorry to say that his last day at Mozilla will be January 12. I 
have appreciated all of Aaron’s work, and it has been a pleasure to work 
with him.


I will be re-assigning all of the root inclusion/update Bugzilla Bugs 
back to me, and I will take back responsibility for the high-level 
verification of the CA-provided data for root inclusion/update requests. 
I will also take back responsibility for verifying CA annual updates, 
and we will continue to work to improve that process and automation via 
the CCADB.


Wayne Thayer, Gerv Markham, and Ryan Sleevi have already taken 
responsibility for the CA Incident bugs 
(https://wiki.mozilla.org/CA/Incident_Dashboard). Thankfully, many of 
you members of the CA Community are helping with this effort.


Wayne and Devon O’Brien will take responsibility for ensuring that 
thorough reviews of CA root inclusion/update requests happen (see 
below), and Wayne will be responsible for the discussion phase of CA 
root inclusion/update requests. We greatly appreciate all of the input 
that you all provide during the discussions of these requests, and are 
especially grateful for the thorough reviews that have been performed 
and documented, with special thanks to Ryan Sleevi, Andrew Whalley, and 
Devon O’Brien.


I think this is a good time for us to make some changes to Mozilla’s 
Root Inclusion Process to improve the effectiveness of the public 
discussion phase by performing the detailed CP/CPS review prior to the 
public discussion. The goal of this change is to focus the discussion 
period on gathering community input and to allow the process to continue 
when no objections are raised.


As such, I propose that we make the following changes to
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

~~ PROPOSED CHANGES ~~

Step 1: A representative of the CA submits the request via Bugzilla and 
provides the information a listed in 
https://wiki.mozilla.org/CA/Information_Checklist.


* Immediate change: None

* Future change: CAs will directly input their Information Checklist 
data into the CCADB.
All root inclusion/update requests will begin with a Bugzilla Bug, as we 
do today. However, we will create a process by which CAs will be 
responsible for entering and updating their own data in the CCADB for 
their request.


Step 2: A representative of Mozilla verifies the information provided by 
the CA.


* Immediate change: None
This will continue to be a high-level review to make sure that all of 
the required data has been provided, per the Information Checklist, and 
that the required tests have been performed.


* Future change: Improvements/automation in CCADB for verifying this data.

Step 3: A representative of Mozilla adds the request to the queue for 
public discussion.


* Immediate change: Replace this step as follows.
NEW Step 3: A representative of Mozilla or of the CA Community (as 
agreed by a Mozilla representative) thoroughly reviews the CA’s 
documents, and adds a Comment in the Bugzilla Bug about their findings. 
If the CA has everything in order, then the Comment will be that the 
request may proceed, and the request will be added to the queue for 
public discussion. Otherwise the Comment will list actions that the CA 
must complete. This may include, but is not limited to fixing 
certificate content, updating process, updating the CP/CPS, and 
obtaining new audit statements. The list of actions will be categorized 
into one of the following 3 groups:

  --- 1: Must be completed before this request may proceed.
  --- 2: Must be completed before this request may be approved, but the 
request may continue through the public discussion step in parallel with 
the CA completing their action items.
  --- 3: Must be completed before the CA’s next annual audit, but the 
request may continue through the rest of the approval/inclusion process.


Step 4: Anyone interested in the CA's application participates in 
discussions of CA requests currently in discussion in the 
mozilla.dev.security.policy forum.


* Immediate Change: Delete this step from the wiki page, because it is a 
general statement that does not belong here.


Step 5: When the application reaches the head of the queue, a 
representative of Mozilla starts the public discussion for the CA in the 
mozilla.dev.security.policy forum.
We prefer that at least two independent parties review and comment upon 
each application.


* Immediate change: Due to the change in Step 3, this step becomes more 
of a time-limited comment period, during which CA Community members may 
raise concern or questions. But if no one posts any concerns in the 
discussion forum, then that will be interpreted as meaning that the CA 
Community does not have concern about the request. So, after the 
specified time, if no concerns are raised, then the discussion will be 
closed, and the request will move on to the approval phase.

Re: DYMO Root CA installed by Label Printing Software

[Jonathan Rudenberg via dev-security-policy]

> On Jan 9, 2018, at 18:42, Peter Gutmann via dev-security-policy 
>  wrote:
> 
> Ryan Sleevi  writes:
> 
>> Of course, if that doesn’t tickle your fancy, there are other ways that are
>> supported that you may not have heard about - for example:
>> https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/native-messaging
>> 
>> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
>> 
>> https://developer.chrome.com/apps/nativeMessaging
> 
> So I've had a quick look at these and unless I've missed something they're
> just a means of talking to an app on your local machine.  As soon as you go
> outside that boundary, e.g. to configure a router or printer on your local
> network via a browser, you're back to having to add a new root CA to the cert
> store for it to work.  Or have I missed something?

Yes, the native messaging API is for communication with local apps. 

For communicating with other machines, the correct thing to do is to issue a 
unique certificate for each device from a publicly trusted CA. The way Plex 
does this is a good example: 
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>Of course, if that doesn’t tickle your fancy, there are other ways that are
>supported that you may not have heard about - for example:
>https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/native-messaging
>
>https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
>
>https://developer.chrome.com/apps/nativeMessaging

So I've had a quick look at these and unless I've missed something they're
just a means of talking to an app on your local machine.  As soon as you go
outside that boundary, e.g. to configure a router or printer on your local
network via a browser, you're back to having to add a new root CA to the cert
store for it to work.  Or have I missed something?

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 10, 2018 at 12:08 AM Peter Gutmann 
wrote:

> Ryan Sleevi  writes:
>
> >Or is your viewpoint that because this happened in the past, one should
> >assume that it will forever happen, no matter how much the ecosystem
> changes -
> >including explicitly prohibiting it for years?
>
> Pretty much.  See the followup message, which shows it was still happening
> as
> of a few months ago.


I fear you critically misunderstood this then.

>one should assume that it will forever happen, no matter how much the
> >ecosystem changes - including explicitly prohibiting it for years?
>
> Buffer overflows, XSS, SQL injection, the list is endless.  None of these
> security issues have gone away, why would another widespread problem,
> issuance
> of certs that shouldn't have been issued, magically disappear just because
> someone says it should?


Because your comparison is tragically flawed? Again, this is something that
was perfectly permissible in 2010 because quite literally no rules existed
on this point.

If you want an analogy, you’re trying to argue that Windows 10 is insecure,
on the basis that you forgot to apply patches to your Windows 95 machine.
Yes, if you didn’t apply patches, your Windows 95 machine was bad. But that
has zero bearing on a discussion about 2018 unless you are intentionally or
unintentionally neglecting the hundreds of systemic changes since then.

Do you honestly believe we won't see more mis-issued
> certs just because the BR says you're not allowed to do it?


Here you switch to arguing they’re misissued (except they weren’t then),
and subsequently confusing the difference between a misissued certificate
(e.g. for localhost) versus a certificate that the subscriber compromises
their own key for (e.g. Blizzard).

These are two entirely separate things.

Just check the
> list over any period of time for examples of the ones that someone's
> actually
> noticed, who knows how many have gone unnoticed until someone like Tavis
> comes along.
>
> >Quick check: will anything you cite newer than 2010?
>
> See my other reply.  I just used the best-known one, which was the first
> that
> came to mind, and shows how widespread the issue was before the naming-and-
> shaming cut some of it down.


Here, you ignore the fact that it wasn’t “naming and shaming” that cut it
down, but quite literally a tectonic shift in the industry and the
introduction of actual requirements. Citing the “best known” is great, but
that’s like citing the best known article that says smoking is good for
you, published in 1950.

Your arguments are like saying that you can go to Walgreens to buy cocaine,
because 100 years ago you could go to the drug store and do so. Or arguing
that anyone can go to the drug store and get enough cold medicine to make
meth, while ignoring the past two decades of increased drug controls.

To your original response, the OP literally gave multiple options that the
industry has acknowledged as significantly better than what you propose as
“best” practice, which is terribly insecure.

To avoid continuing to rathole on just how misguided the initial response
was - and how woefully out of date - I’ll circle back with priorities:

- You can use http://127.0.0.1
- You can generate a local CA cert on installation (as numerous products do)
- You can generate a local *non* CA cert and install t as trusted for your
users for just that site
- You can use the browser’s native messaging APIs
- You can generate a FQDN and deliver certs to your users from publicly
trusted CAs (as long as the client generated the local key) - If you’re not
familiar with this,
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

You should not:
- Have the vendor generate the leaf key (as the OP pointed out as troubling)
- Have the vendor generate the CA key themselves (as Peter suggested)
- Ship a private key within the app

That is best practice here in 2018.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>Or is your viewpoint that because this happened in the past, one should
>assume that it will forever happen, no matter how much the ecosystem changes -
>including explicitly prohibiting it for years?

Pretty much.  See the followup message, which shows it was still happening as
of a few months ago.

>one should assume that it will forever happen, no matter how much the
>ecosystem changes - including explicitly prohibiting it for years?

Buffer overflows, XSS, SQL injection, the list is endless.  None of these
security issues have gone away, why would another widespread problem, issuance
of certs that shouldn't have been issued, magically disappear just because
someone says it should?  Do you honestly believe we won't see more mis-issued
certs just because the BR says you're not allowed to do it?  Just check the
list over any period of time for examples of the ones that someone's actually
noticed, who knows how many have gone unnoticed until someone like Tavis
comes along.

>Quick check: will anything you cite newer than 2010?

See my other reply.  I just used the best-known one, which was the first that
came to mind, and shows how widespread the issue was before the naming-and-
shaming cut some of it down.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Ryan Sleevi via dev-security-policy]

On Tue, Jan 9, 2018 at 11:12 PM Peter Gutmann 
wrote:

> Ryan Sleevi  writes:
>
> >First, there are non-commercial CAs that are trusted.
>
> By "commercial CAs" I meant external business entities, not an in-house CA
> that the key or cert owner controls.  Doesn't matter if they charge money
> or
> not, you still need to go to an external organisation to ask permission to
> use
> encryption.
>
> >Second, you'e stated "there are many commercial CAs who will happily sell
> you
> >a cert for 'localhost'". To that, I say POC||GTFO,
>
> “An Observatory for the SSLiverse”, Peter Eckersley and Jesse Burns,
> presentation at Defcon 18, July 2010,
> http://www.eff.org/files/DefconSSLiverse.pdf.  That lists *six thousand*
> certs
> issued for localhost from Comodo, Cybertrust, Digicert, Entrust, Equifax,
> GlobalSign, GoDaddy, Microsoft, Starfield, Verisign, and many others.  Then
> there's tens of thousands of certs that other studies have found for
> unqualified names, RFC 1918 names, and so on.
>
> (The naming-and-shaming via CT is certainly cutting down on this, but given
> the widespread mis-issuance of these certs in the past, are you really
> confident that it's not still happening when CT can't see it?).


It’s 2018. That practice has been banned for five years. It wasn’t banned
at the time. Heck, the Baseline Requirements didn’t even exist at the time
of that paper - and yet compliance to them has been a Mozilla Program
requirement for years and literally thousands of messages in this Forum
have been discussing them since their adoption. In 2012.

I appreciate your many contributions over the years, but it is extremely
misleading, borderline disingenuous to make such broad claims about the
state of the PKI today based on the ecosystem in 2010.

Would you feel your claim is any more appropriate or valid than a claim
that there are many CAs that will issue you SHA-1 certs or 1024-bit RSA key
certs, in 2018, simply because they did in 2010?

Or is your viewpoint that because this happened in the past, one should
assume that it will forever happen, no matter how much the ecosystem
changes - including explicitly prohibiting it for years?


>
> >Third, I'm happy to inform you there is a correct way. The Secure Contexts
> >spec ( https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy )
>
> ... available on display in the bottom of a locked filing cabinet stuck in
> a
> disused lavatory with a sign on the door saying "Beware of the Leopard".


Well, no, it only seems that way because well-intentioned, but woefully
misinformed people will often be the first to reply, and then that bad
information continues to propagate, with plenty of excuses why they were
“technically” right or niggling on some minor semantic detail, all the
while happily believing their wrong way is the right way and promoting it
as such.

Given that a number of vendors have resorted to hardcoding their own root
> CAs,
> Secure Contexts is either not working or there's insufficient awareness of
> it
> for it to be effective (or both).  Having just skimmed parts of that
> lengthy
> and complex spec, which I'd never heard of until now, it's pretty hard to
> see
> what this actually gives me, and that it can (according to you) make
> connecting to localhost secure.  In particular the text "The following
> features are at-risk, and may be dropped during the CR period: [...] The
> localhost carveout" and "This carveout is 'at risk', as there’s currently
> only
> one implementation" doesn't inspire confidence either in it being widely
> supported or it continuing to be supported.


127.0.0.1 works.

“Localhost” has mixed support, due to the fact that several OSes will send
“localhost” traffic over the internet connection and dns server, allowing
anyone to claim to be your localhost.

Of course, if that doesn’t tickle your fancy, there are other ways that are
supported that you may not have heard about - for example:
https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/native-messaging

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging

https://developer.chrome.com/apps/nativeMessaging

These also offer secure communication channels, such as the use case the OP
raised.

>There are other remarks in your response that are also wrong, but in the
> >spirit of only focusing on the most important (to this specific reporter's
> >question), I've omitted them.
>
> Please, go ahead.  I'm happy to defend them, with references to studies and
> whatnot if available.


Quick check: will anything you cite newer than 2010?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>First, there are non-commercial CAs that are trusted. 

By "commercial CAs" I meant external business entities, not an in-house CA
that the key or cert owner controls.  Doesn't matter if they charge money or
not, you still need to go to an external organisation to ask permission to use
encryption.

>Second, you'e stated "there are many commercial CAs who will happily sell you
>a cert for 'localhost'". To that, I say POC||GTFO, 

“An Observatory for the SSLiverse”, Peter Eckersley and Jesse Burns,
presentation at Defcon 18, July 2010,
http://www.eff.org/files/DefconSSLiverse.pdf.  That lists *six thousand* certs
issued for localhost from Comodo, Cybertrust, Digicert, Entrust, Equifax,
GlobalSign, GoDaddy, Microsoft, Starfield, Verisign, and many others.  Then
there's tens of thousands of certs that other studies have found for
unqualified names, RFC 1918 names, and so on.

(The naming-and-shaming via CT is certainly cutting down on this, but given
the widespread mis-issuance of these certs in the past, are you really
confident that it's not still happening when CT can't see it?).

>Third, I'm happy to inform you there is a correct way. The Secure Contexts
>spec ( https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy )

... available on display in the bottom of a locked filing cabinet stuck in a
disused lavatory with a sign on the door saying "Beware of the Leopard".

Given that a number of vendors have resorted to hardcoding their own root CAs,
Secure Contexts is either not working or there's insufficient awareness of it
for it to be effective (or both).  Having just skimmed parts of that lengthy
and complex spec, which I'd never heard of until now, it's pretty hard to see
what this actually gives me, and that it can (according to you) make
connecting to localhost secure.  In particular the text "The following
features are at-risk, and may be dropped during the CR period: [...] The
localhost carveout" and "This carveout is 'at risk', as there’s currently only
one implementation" doesn't inspire confidence either in it being widely
supported or it continuing to be supported.

>There are other remarks in your response that are also wrong, but in the
>spirit of only focusing on the most important (to this specific reporter's
>question), I've omitted them. 

Please, go ahead.  I'm happy to defend them, with references to studies and
whatnot if available.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Ryan Sleevi via dev-security-policy]

On Tue, Jan 9, 2018 at 4:40 PM, Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Nicholas Humfrey via dev-security-policy  mozilla.org> writes:
>
> >What is the correct way for them to achieve what they are trying to do?
>
> I'm not sure if there is a correct way, just a least awful way.  The
> problem
> is that the browser vendors have decreed that you can only talk SSL if you
> use
> a certificate from a commercial CA, which obviously isn't possible in this
> case, or in numerous other cases (well, there are many commercial CAs who
> will
> happily sell you a cert for "localhost", but that's another story).
>

Hi Peter,

This is factually false on several dimensions, so I think it bears calling
out.

First, there are non-commercial CAs that are trusted. This isn't about
commercial/non-commercial, but a question about whether trusted by default
or not. Obviously, those which are not trusted by default are necessarily
required to do something not default.

Second, you'e stated "there are many commercial CAs who will happily sell
you a cert for 'localhost'". To that, I say POC||GTFO, or, less profanely,
please provide examples so CA incident reports can be filed. This is
certainly not true enough to justify 'many', and the CA incident reports
shows that the certs we're dealing with today are primarily the result of
CAs that failed to revoke back when they should have, not that they've
continued issuance.

Third, I'm happy to inform you there is a correct way. The Secure Contexts
spec ( https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy )
describes how localhost can be considered apriori trustworthy - that is,
loading http://localhost 'just works' and doesn't trigger mixed content.

There are other remarks in your response that are also wrong, but in the
spirit of only focusing on the most important (to this specific reporter's
question), I've omitted them. Certainly, it's not the minimal security risk
as you state - and messages over the past few weeks in this very Forum
capture that past discussion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Hanno Böck via dev-security-policy]

Hi,

On Tue, 09 Jan 2018 21:04:34 +
Nicholas Humfrey via dev-security-policy
 wrote:

> What is the correct way for them to achieve what they are trying to
> do?
> 
> Would it be better to use a self-signed localhost certificate (same 
> subject and
> issuer), generated individually on each machine it is installed on?

I covered this in detail in the last Bulletproof TLS Newsletter:
https://www.feistyduck.com/bulletproof-tls-newsletter/

Creating a local root on each host individually *with an individual
private key* is kinda okay. The cleaner solution is to connect via http
and the localhost IP (127.0.0.1), which should not throw mixed
contentwarnings - however not all browsers support that yet.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DYMO Root CA installed by Label Printing Software

[Peter Gutmann via dev-security-policy]

Nicholas Humfrey via dev-security-policy 
 writes:

>What is the correct way for them to achieve what they are trying to do?

I'm not sure if there is a correct way, just a least awful way.  The problem
is that the browser vendors have decreed that you can only talk SSL if you use
a certificate from a commercial CA, which obviously isn't possible in this
case, or in numerous other cases (well, there are many commercial CAs who will
happily sell you a cert for "localhost", but that's another story).

So you can hack something with "the cloud", but now your label printing
software relies on external internet access to work, and you're sending
potentially sensitive data that never actually needs to go off-site, off-site
for no good reason.

Perhaps the least awful way is to install a custom root CA cert that only ever
signs one cert, "localhost" (and the CA's private key is held by Dymo, not
hardcoded into the binary).  You've got a shared private key for localhost,
but it's less serious than having a universal root CA there.

The problem is really with the browsers, not with Dymo.  There's no easy
solution from Dymo's end, so what they've done, assuming they haven't
hardcoded the CA's private key, is probably the least awful workaround to the
problem.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DYMO Root CA installed by Label Printing Software

[Nicholas Humfrey via dev-security-policy]

Hello,

Apologies if this is off-topic but I am not sure where else to query 
this.


While going through the list of Root Certificate Authorities on my 
computer, I
was alarmed to discover one I wasn't expecting there, called "DYMO Root 
CA (for
localhost)". This certificate was installed by the label printing 
software, I

installed for my DYMO Label Printer.

It is intended purpose is to allow web-based tools to send content to 
the label
printer to be printed by the local machine. It does it by allowing your 
web

browser to access a web server running on your local computer.

It appears that they are installing the same Root CA and localhost 
certificate
on each machine the printer software is installed on. On my Mac it was 
installed

into the System keychain, as well as the Firefox list of Authorities.

There are screenshots and more details here:
https://github.com/njh/dymo-root-ca-security-risk



What is the correct way for them to achieve what they are trying to do?

Would it be better to use a self-signed localhost certificate (same 
subject and

issuer), generated individually on each machine it is installed on?

Should 'localhost' / Mixed Content work without a certificate?

Or should they have a printer daemon on the local machine talking back 
to a

cloud service, that the browser talks to?



Thanks,

nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Serial number length

[Gervase Markham via dev-security-policy]

Hi,

On 29/12/17 06:24, Jakob Bohm wrote:
> 1. Do all recently issued certificates have to contain at least 64 bits
>   of randomness in their serial numbers?

Yes. (References given by others.)

> 2. Is it acceptable for a CA to satisfy this requirement by generating
>   random 64 bit serial numbers and checking if there is a certificate
>   with that random serial before using it?

IMO Yes. The requirement is specifically to include 64 bits of output
from a CSPRNG. Bits don't stop being from a CSPRNG just because they've
compared unequally with a list of other sets of bits.

> 3. Or would the elimination in #2 reduce the entropy of such serial
>   numbers to slightly less than 64 bits (since there are less than 2**64
>   allowed values for all but the first such certificate)?

Technically, it would, but I don't think that's a problem as the
requirement is written, and I don't think it's a problem in practice
because the entropy reduction is so slight and the error margin is
intentionally large.

2^64 is 18,446,744,073,709,552,000. Even if you issue a billion
certificates, the entropy reduction is 0.001%. (May be off by an
order of mag. or two, but roughly that.)

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Dashboard and Study on CAA Adoption

[Gervase Markham via dev-security-policy]

Hi Quirin,

On 15/12/17 15:09, Quirin Scheitle wrote:
> The results, paper, and a dashboard tracking CAA adoption are available under 
> 
> https://caastudy.github.io/

Belatedly, thank you and your colleagues for doing this excellent work.

It is interesting that you have received no iodef messages at all. I can
imagine CAs deprioritizing that work in favour of getting their
implementations right. I can see a time, when CAA implementations have
settled down and are reliable, that we might look at mandatory reporting
of attempted misissuance.

CAs are already able to use CA-specific tags to restrict particular
validation methods and certificate types; this is something I think it's
reasonable to let the market provide if there is demand.

The DNS operator privilege is there because it doesn't make too much
sense for an organization to ask itself for permission to issue.

I would expect CAs to be storing the results of their CAA lookups in
their issuance logs, in sufficient detail for them to be checked later,
even if they are not published.

I share your hope that the deployment and use of CAA, and the accuracy
and consistency of checking, will improve in the days ahead. It will be
fascinating if you are able to repeat this research in six or twelve
months time.

One other quote:

"For 1 domain, our scans showed a CAA configuration that
consistently did not permit any CA to issue, yet a certificate
was issued during this time. Upon inquiry, the domain name
holder confirmed that they had fully automated their certifi-
cate issuance process, including automatic reconfiguration of
CAA records for a brief time period."

That's pretty awesome :-)

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Misissued certificate

[Francesc Ferrer via dev-security-policy]

Dear all, 

 

In response to Mr. Gaynor email reporting a mis-issued certificate, the owner 
of the certificate has been contacted and request its revocation. Our 
compromise is to have it revoked by this afternoon at most. 

 

After reviewing the problem, we believe that given the issuance date of the 
reported certificate (Jul 29 07:13:34 2016 GMT), this is another case of 
"Non-BR-Compliant Certificate" that it was not detected when the following bug 
was filed and treated:

 

https://bugzilla.mozilla.org/show_bug.cgi?id=1390988 

 

We will perform further investigations in order to see if there are more cases 
we missed at that moment. We will also check if the conditions that allowed our 
system to issue this certificate are consistent with the problem and corrective 
actions already reported in the existing bug. If not, we will file a new bug. 

 

Looking forward to your comments, 

 

Thank you, 

 


_

 




_
_


Francesc Ferrer i Grevolosa
Àrea de Tecnologia
Consorci Administració Oberta de Catalunya
Tànger, 98 (planta baixa) 08018 Barcelona
tel: 93 272 40 00
  www.aoc.cat - @consorciaoc

"Impulsem la transformació digital de les Administracions Catalanes, per 
promoure Governs Àgils, Lògics i Col·laboratius "

 
Aquest correu electrònic, així com qualsevol fitxer annex, conté informació 
classificada. Queda prohibida la seva divulgació, còpia o distribució a 
persones diferents del seu destinatari exclusiu sense autorització prèvia per 
escrit del Consorci Administració Oberta de Catalunya. Si vostè ha rebut aquest 
correu electrònic per error, si us plau notifiqui-ho immediatament al remitent 
reenviant-lo.

 

 

De: Alex Gaynor [mailto:agay...@mozilla.com] 
Enviado el: dilluns, 8 de gener de 2018 20:53
Para: incident_pki 
Asunto: Misissued certificate

 

Hello,

 

I'm reporting a mis-issued certificate: https://crt.sh/?id=284511547 
 =cablint

 

The dNSName SAN in this certificate is not a domain name, but is instead a URI, 
in violation of RFC5280/BRs. I am requesting this certificate be revoked and a 
post-mortem sent to the mozilla.dev.security.policy mailing list.

 

Thanks,

Alex



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy