Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Alex Cohn via dev-security-policy]

On Fri, Aug 30, 2019 at 10:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond good. However, if "a promise to issue a
> certificate" is not the same as issuance, the BRs don't apply to the OCSP
> until the certificate issues and the correct response is "Revoked" per the
> RFC.
>
> The BRs apply for sure to the contents, but do they apply to the OCSP
> responses in the time period between when the pre-cert is logged and the
> cert is signed.
>

It seems reasonable to me to assume that if the contents of a
precertificate are in-scope for the BRs, the OCSP responses would be
likewise in-scope.


> Seems like a nice simple rule is that the promise to issue is issuance
> regardless of what the BRs say and that you should respond good. This was
> our logic and why we decided on "Good".


I agree. A CA cannot prove they didn't issue the final certificate. Given
existence of a pre-certificate, it is reasonable for a relying party to
assume that the final certificate exists and therefore that OCSP services
will be functional. I personally would view arguments such as "we didn't
actually issue that, so we don't need to provide sane OCSP responses" with
a great deal of skepticism, especially from CAs that do not automatically
CT log their final certificates (nudge nudge DigiCert, Amazon, Entrust).

However, a very strict reading of the RFC and BR interaction means you need
> to respond "Revoked" until the cert issues. I don't like that outcome
> because it's complicated and leads to confusion.


Looking at sections 2.2 of RFC6960 and 4.9.10 of the BRs, I don't see the
requirement to respond "revoked" for unknown or non-issued certificates -
can you explain further? 4.9.10 forbids replying "good" for non-issued
certificates, but I don't see any stipulations surrounding replying
"unknown." The certificateHold + 1970-1-1 revocation date method of
indicating a non-issued certificate in 6960 2.2 might be forbidden by an
especially strict reading of BRs 4.9.13, but it's not mandated by 6960. In
the absence of a precertificate signing certificate, OCSP queries for
precertificate and certificate are identical, so it could be argued that
the precertificate itself means it's not a "non-issued" certificate?

>From a RP's perspective, I can easily envision problems resulting from an
OCSP response for a given serial number transitioning from revoked to good,
especially if the response is cached by the relying party or a proxy.

It also occurred to me that CAs using a precertificate signing certificate
(e.g. Trustwave or NetLock) would be able to differentiate OCSP requests
for precertificates from final certificates. How do these CAs handle OCSP
for precertificates? Trustwave appears to always answer "unauthorized
" and NetLock "malformed
", which is...curious.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Fri, 30 Aug 2019 12:02:42 -0500
Matthew Hardeman via dev-security-policy
 wrote:

> What's not discussed in that mechanism is how Google decides what
> pages are unsafe and when?

Yes, but the point was to show what shape Safe Browsing API is, I guess
I'd assumed this makes it obvious that EV doesn't really fit well but
didn't spell that out properly.

Google doesn't end up able to interrogate whether the site the user is
visiting presented them an EV certificate. Indeed in most cases it will
have no idea they visited a site, let alone which certificate was
presented.

But yes, it would be possible to use EV as an input to a manual
process to create the list of phishing pages. It would also be possible
to use astrology. If I were tasked with this I would not do either.


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[James Burton via dev-security-policy]

Kirk,

I know you are really passionate about extended validation and it does
come across in your correspondences on this forum and the CAB Forum
but sometimes our passion or frustration leads us to divulge private
information which shouldn't have been released into the public domain.
Before you post any other correspondences to this forum or any other
forum, give it a check over or leave it until you are in a better
frame of mind. You don't want to accidentally break the NDA agreements
you have signed over the course of your work.

Thank you,

Burton

On Fri, Aug 30, 2019 at 8:45 PM Kirk Hall via dev-security-policy
 wrote:
>
> On Friday, August 30, 2019 at 11:38:55 AM UTC-7, Peter Bowen wrote:
> > On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > I'll just reiterate my point and then drop the subject.  EV certificate
> > > subject information is used by anti-phishing services and browser phishing
> > > filters, and it would be a loss to the security ecosystem if this EV data
> > > disappears (meaning that the decision on removal of the EV UI has greater
> > > repercussions than just whether or not users can tell in the primary UI if
> > > their website does or does not have any confirmed identity information).
> > >
> >
> > Kirk,
> >
> > I have to admit that the first time I ever heard of browser phishing
> > filters and Internet security products (such as Trend Micro, Norton,
> > Mcafee, etc) differentiating between DV and EV SSL certificates as part of
> > their algorithm is in this thread, from you.  As someone who has a website,
> > I would really appreciate it if you could point to where this is
> > documented.  This morning I looked at a couple of network security vendor
> > products I've used and couldn't find any indication they differentiate, but
> > if there are ones that do it would certainly influence my personal decision
> > on the kind of certificates to use and to recommend others to use.
> >
> > I'm not personally aware of anyone doing this.  Are you aware of any
> > product literature that discusses this?
> >
> > Thanks,
> > Peter
>
> I have some emails out asking permission to share information that was given 
> to us in the past.  If I receive permission, I will post something further.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Friday, August 30, 2019 at 11:38:55 AM UTC-7, Peter Bowen wrote:
> On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I'll just reiterate my point and then drop the subject.  EV certificate
> > subject information is used by anti-phishing services and browser phishing
> > filters, and it would be a loss to the security ecosystem if this EV data
> > disappears (meaning that the decision on removal of the EV UI has greater
> > repercussions than just whether or not users can tell in the primary UI if
> > their website does or does not have any confirmed identity information).
> >
> 
> Kirk,
> 
> I have to admit that the first time I ever heard of browser phishing
> filters and Internet security products (such as Trend Micro, Norton,
> Mcafee, etc) differentiating between DV and EV SSL certificates as part of
> their algorithm is in this thread, from you.  As someone who has a website,
> I would really appreciate it if you could point to where this is
> documented.  This morning I looked at a couple of network security vendor
> products I've used and couldn't find any indication they differentiate, but
> if there are ones that do it would certainly influence my personal decision
> on the kind of certificates to use and to recommend others to use.
> 
> I'm not personally aware of anyone doing this.  Are you aware of any
> product literature that discusses this?
> 
> Thanks,
> Peter

I have some emails out asking permission to share information that was given to 
us in the past.  If I receive permission, I will post something further.  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 30, 2019 at 12:06 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is super easy, and doesn't even require you to do any work, like
> contacting Google Safe Browsing and asking them to participate in this
> conversation.
>
> Here's the question, and all I'm asking you to do is answer "Yes," "No,"
> or "I Don't Know"
>
> **Based on your personal knowledge, does Google Safe Browsing use any EV
> certificate Subject information in its anti-phishing algorithms?**


That is indeed the question I was asking you, and I hope you can answer.
Will you answer it?

To recall, since you've shifted the conversation rather substantially, and
thus perhaps forgotten the original question, which you've repeatedly
avoided:
- You made a definitive claim this information is used by one or more
parties, and described how it was used.
- I asked for details, to understand how they address the obvious issues
with using it like this.

If you have personal knowledge that GSB uses it like you described, it's
reasonable to ask to report back as to how those issues are addressed, from
whoever you obtained this knowledge from.

If you do not have personal knowledge that GSB uses it like you described,
then continuing to discuss GSB is not useful for this discussion.

I had thought the question originally asked, of your bold claim, was
simple. I'm not sure why you've focused on trying to find out new
information, rather than simply sharing more information about what you
presented.

It would be very useful information to everyone on this list if you would
share any sort of information about what you described. Since you made it
clear you knew of some organizations using this, it seemed reasonable that
you could ask them how they address this, without having to reveal who they
are. After all, if they're comfortable with you sharing that they do this,
surely they'd have no problem with you sharing, anonymously, how they solve
it.

Thanks for your cooperation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond good.


Citation needed ;-)


> However, if "a promise to issue a certificate" is not the same as
> issuance, the BRs don't apply to the OCSP until the certificate issues and
> the correct response is "Revoked" per the RFC.
>

That would be... inadvisable, as you'd be unrevoking a certificate, which
would definitely Be An Issue (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=1532333 )

I definitely want to make sure any confusion is resolved. Can you point to
any Mozilla policies or comms that use the phrase "promise to issue a
certificate" so we can clarify? It's unclear to me if it's being used as an
unfortunate shorthand (and special apologies if I've contributed to that).

RFC 6962, Section 3.1, phrases it as such:
   "The signature on the TBSCertificate indicates the certificate
authority's intent to issue a certificate. This intent is considered
binding (i.e., misissuance of the Precertificate is considered equal
to misissuance of the final certificate)."

(Some past discussion at
https://groups.google.com/d/topic/mozilla.dev.security.policy/Hk78klSv8AY/discussion
)

In various discussions, this has been attempted to be further clarified: If
a precertificate exists, for all intents and purposes of all policy
obligations, an equivalent certificate is presumed to exist, as the CA has
signaled a binding intent to do so. As a consequence, regardless of whether
or not we "see" the certificate, it should be presumed to exist, and the
OCSP status and any other certificate services, databases, or other should
be presumed to exist.

The BRs apply for sure to the contents, but do they apply to the OCSP
> responses in the time period between when the pre-cert is logged and the
> cert is signed.
>
> Seems like a nice simple rule is that the promise to issue is issuance
> regardless of what the BRs say and that you should respond good. This was
> our logic and why we decided on "Good". However, a very strict reading of
> the RFC and BR interaction means you need to respond "Revoked" until the
> cert issues. I don't like that outcome because it's complicated and leads
> to confusion.


Agreed that it's nonsense, but I don't see how the strict reading can lead
to that conclusion. There's more statuses than the binary Good/Revoked, and
that's extremely relevant (and the BRs Have Opinions on which statuses you
can and should use for certs you don't know about)

Despite all of the writing above, I'm too lazy to copy/paste my comment
from the Let's Encrypt issue, but I would hope any CA contemplating things
should look at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652#c3 in
terms of a possible 'ideal' flow, and to share concerns or considerations
with that. Even better would be CAs that have suggestions on how best to
codify and memorialize that suggestion, if it's sensible and correct.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Google Trust Services - CRL handling of expired certificates not fully compliant with RFC 5280 Section 3.3

[Andy Warner via dev-security-policy]

This is an initial report and we expect to provide some additional details and 
the completion timeline after a bit more verification and full deployment of 
in-flight mitigations. We are posting the most complete information we have 
currently to comply with Mozilla reporting timelines and will follow-up with 
additional details soon.

1. How your CA first became aware of the problem and the time and date.

While performing an internal review and assessment of the CRL generation system 
for Google Trust Services' GTS CA 1O1 on August 16, 2019, it was discovered 
that the CRL generation service did not include CRL entries of expired 
certificates. The periodic job only considered certificates with valid 
lifetimes. This does not conform to RFC 5280 Section 3.3 which states that “An 
entry MUST NOT be removed from the CRL until it appears on one regularly 
scheduled CRL issued beyond the revoked certificate's validity period.”  We 
expect that few, if any, clients have been impacted.  For a client to be 
impacted they would have to: clock skewed to a time before the not-after field 
of the certificate; and have a CRL published after expiration dropping the 
revoked certificate.


2. A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done.

August 16, 2019 15:00 UTC - Reviewer realizes that CRL will not publish for one 
update past expiration
August 16, 2019 16:00 UTC - Reviewer checks for other issues & talks to peers 
to confirm problem
August 16, 2019 17:00 UTC - Bug is filed to fix the issue with a proposed 
design fix
August 16, 2019 23:30 UTC - Fix is sent for review
August 20, 2019 16:00 UTC - Remediation work is discussed & assigned
August  20, 2019 18:00 UTC - Query to inspect revoked certificates is created 
and sent to be run by production team for initial analysis.
August 21, 2019 10:40 UTC - Production team runs query and returns result
August 21, 2019 15:00 UTC - Reviewer analyzes data
August 21, 2019 20:30 UTC - Reviewer asks for a follow up query to ascertain if 
any certificates did not make it onto the CRL 
August 22, 2019 07:00 UTC - Initial attempt at updating test systems with fix.
August 22, 2019 09:00 UTC - Updating of test systems aborted due to (unrelated) 
issues.
August 22, 2019 07:00 UTC - Production team runs query for CRLs that may have 
missed a certificate
August 22, 2019 15:00 UTC - Reviewer ascertains that certificates under 
question were on a CRL
August 26, 2019 11:00 UTC - Second attempt at updating test systems with fix.
August 26, 2019 13:00 UTC - Test systems updated, confirmed integrity of fixed 
software.
August 27, 2019 09:00 UTC - Confirmed fix is effective on test systems.
August 27, 2019 10:00 UTC - present: Ongoing staged deployment to production 
systems. Should complete fully by September 3, 2019 17:00 UTC (slightly 
extended window due to push policies around holiday weekends. The rollout was 
staged in accordance with Google's standard rollout procedures.)


3. Whether your CA has stopped, or has not yet stopped, issuing certificates 
with the problem. 

The affected CA software has been patched.  It now populates expired 
certificates in the CRL for 7 days after their expiration to ensure they appear 
in at least one regularly issued CRL update.  Automated testing was added as 
part of the same patch to check that revoked certificates are kept in the CRL.  
The patch was developed, tested, reviewed and landed within the codebase by 
August 19, 2019.  The CRL entry removal bug has been fully remediated.


4. A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem were issued.

Investigation began on August 20, 2019 to discover the potential impact of the 
logic bug. The CRL generation had contained the bug since its inception, 
affecting all issuance under GTS 1O1 since March 2018. There were 200,263 
revoked certificates during that time window. Almost all certificates were for 
internal monitoring specific to checking revocation. The few non-monitoring 
certificates were all revocations by clients following rotation of certificates 
and not due to compromises.


5. The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.

crt.sh IDs to follow, waiting on confirmation that the 2 test certificates 
mentioned below are the only cases where the issue was surfaced.

The team looked for revoked certificates from first issuance that never 
appeared within a published CRL from operation of CA until August 21, 2019.

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Peter Bowen via dev-security-policy]

On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I'll just reiterate my point and then drop the subject.  EV certificate
> subject information is used by anti-phishing services and browser phishing
> filters, and it would be a loss to the security ecosystem if this EV data
> disappears (meaning that the decision on removal of the EV UI has greater
> repercussions than just whether or not users can tell in the primary UI if
> their website does or does not have any confirmed identity information).
>

Kirk,

I have to admit that the first time I ever heard of browser phishing
filters and Internet security products (such as Trend Micro, Norton,
Mcafee, etc) differentiating between DV and EV SSL certificates as part of
their algorithm is in this thread, from you.  As someone who has a website,
I would really appreciate it if you could point to where this is
documented.  This morning I looked at a couple of network security vendor
products I've used and couldn't find any indication they differentiate, but
if there are ones that do it would certainly influence my personal decision
on the kind of certificates to use and to recommend others to use.

I'm not personally aware of anyone doing this.  Are you aware of any
product literature that discusses this?

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

> OK, I'll try one last time to see if you are willing to share Google 
> information that you have with this group on the question at hand (Do browser 
> phishing filters and anti-virus apps use EV data in their anti-phishing 
> algorithms).  
> 
> This is super easy, and doesn't even require you to do any work, like 
> contacting Google Safe Browsing and asking them to participate in this 
> conversation.
> 
> Here's the question, and all I'm asking you to do is answer "Yes," "No," or 
> "I Don't Know"
> 
> **Based on your personal knowledge, does Google Safe Browsing use any EV 
> certificate Subject information in its anti-phishing algorithms?**
> 
> This will be useful information to everyone on this list.
> 
> Thanks for your cooperation.

I want to withdraw the question above that I posed to Ryan - I posted this last 
night in frustration, but I was wrong to put someone on the spot like that.

I'll just reiterate my point and then drop the subject.  EV certificate subject 
information is used by anti-phishing services and browser phishing filters, and 
it would be a loss to the security ecosystem if this EV data disappears 
(meaning that the decision on removal of the EV UI has greater repercussions 
than just whether or not users can tell in the primary UI if their website does 
or does not have any confirmed identity information).

I hope Mozilla will pivot to a redesigned EV UI (instead of removing it 
entirely) like the Apple UI (green lock and URL when EV identity is present, 
black lock symbol/UI for anonymous sites).  

That solution (1) seems to satisfy the concerns Mozilla started with (that 
users don't understand specific ownership data presently shown in the Firefox 
UI), (2) allows users to know the identity status of a website before they 
enter their password or credit card number, (3) would allow for easy user 
training on the meaning of the new Firefox UI, (4) would continue to 
incentivize enterprise website owners to continue using EV certificates, 
thereby continuing to populate the security ecosystem with very useful data 
related to website domains that can be used for anti-phishing purposes, (5) 
work very well in a mobile environment where space is limited, (6) probably 
represent a modest engineering effort to make the change and maintain it, and 
(7) start the process of creating a common UI among different browsers (Apple 
is there already), which can only be good for user security.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matthew Hardeman via dev-security-policy]

On Fri, Aug 30, 2019 at 11:56 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> For readers unfamiliar, let me briefly explain what Safe Browsing gives
> browsers:
>
> For every URL you're considering displaying you calculate a whole bunch
> of cryptographic hashes, of the whole URL, just the FQDN and certain
> other combinations. Then you truncate the hashes and you see if the
> truncated hashes are in a small list Google gave you (a browser will
> update this list periodically using a synchronisation API Google
> designed for the purpose).
>
> If one of your truncated hashes /is/ in the list, maybe this is
> Phishing! You call Google, telling them the truncated hash you are
> worried about, and Google gives you a complete list of full (not
> truncated) hashes you should worry about with this prefix. It might be
> empty (the phishing attack is gone) or have multiple entries.
>
> Only if the full hash you were worried about is in that fresh list from
> Google do you tell the user "Ohoh. Phishing, probably go somewhere
> else" in all other cases everything is fine.
>

What's described here is how the browser determines with the service
whether the page you visit is on the list of what Google considers to be a
likely unsafe page.

What's not discussed in that mechanism is how Google decides what pages are
unsafe and when?

Say, for example, you're actively monitoring a property that historically
has had EV presentation.  For high value sites, especially in finance,
perhaps the database notes that EV is "normal" for the site.  If subsequent
checks against that site lack EV, perhaps it flags a human review to
determine if the site has been hijacked.  Perhaps it combines the change of
EV status with a change in other underlying elements (new / different a-DNS
set, A records resolving to suspicious IP space, etc.)  But I'm not sure we
can really know, unless they're willing to say.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Thu, 29 Aug 2019 18:44:11 -0700 (PDT)
Kirk Hall via dev-security-policy
 wrote:

> OK, I'll try one last time to see if you are willing to share Google
> information that you have with this group on the question at hand (Do
> browser phishing filters and anti-virus apps use EV data in their
> anti-phishing algorithms).  

For the AV apps I can totally believe they'd do this because bogus
assumptions are more or less their bread and butter. "It's an EV cert
so it's safe" is exactly the kind of logic I can imagine them employing.

But it really doesn't seem like a good fit for Google Safe Browsing,
if they do try to triangulate from EV that seems like a big leap to me.

For readers unfamiliar, let me briefly explain what Safe Browsing gives
browsers:

For every URL you're considering displaying you calculate a whole bunch
of cryptographic hashes, of the whole URL, just the FQDN and certain
other combinations. Then you truncate the hashes and you see if the
truncated hashes are in a small list Google gave you (a browser will
update this list periodically using a synchronisation API Google
designed for the purpose).

If one of your truncated hashes /is/ in the list, maybe this is
Phishing! You call Google, telling them the truncated hash you are
worried about, and Google gives you a complete list of full (not
truncated) hashes you should worry about with this prefix. It might be
empty (the phishing attack is gone) or have multiple entries.

Only if the full hash you were worried about is in that fresh list from
Google do you tell the user "Ohoh. Phishing, probably go somewhere
else" in all other cases everything is fine.


This design has important privacy properties because it means Google
definitely isn't told which pages you visit, and ordinarily it doesn't
even learn roughly how many pages you're visiting or anything like
that. Only when you try to visit a phishing site, or there's a random
coincidence, it learns (if it chooses to remember) that someone from
your IP either tried to visit a phishing site or there was a random
coincidence, and not which of those options it was.

Most Phishing detections aren't for a whole site, they are
page-specific. So maybe jims-oil-change.example is a perfectly
legitimate site for Jim the auto mechanic with a Let's Encrypt cert, but
his poorly configured PHP setup means bad guys create
https://jims-oil-change.example/.temp/PayPal.com/security which is a
PayPal phish form.

The Safe Browsing design lets Google add the hash for that nasty
phishing page, without also making Jim's harmless front page get an
angry message in browsers.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matthew Hardeman via dev-security-policy]

>
> I’m not saying that this is the case, but merely to say that the
> Yes/No/IDK does not represent the full set of feasible responses.
>

So let's add "I decline to make inquiries, official or otherwise" and
"Policy prevents me from discussing that" to the list.  It would be
interesting to get one of any of the mentioned responses back.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Neil Dunbar via dev-security-policy]

> On 30 Aug 2019, at 02:44, Kirk Hall via dev-security-policy 
>  > wrote:
> 
> OK, I'll try one last time to see if you are willing to share Google 
> information that you have with this group on the question at hand (Do browser 
> phishing filters and anti-virus apps use EV data in their anti-phishing 
> algorithms).  
> 
> This is super easy, and doesn't even require you to do any work, like 
> contacting Google Safe Browsing and asking them to participate in this 
> conversation.
> 
> Here's the question, and all I'm asking you to do is answer "Yes," "No," or 
> "I Don't Know"
> 
> **Based on your personal knowledge, does Google Safe Browsing use any EV 
> certificate Subject information in its anti-phishing algorithms?**

Kirk,

There is also the possibility that Ryan may have such knowledge, but absent 
permission from his employer, he is not at liberty to disclose internal company 
policies and procedures on an open forum. Indeed, it would not surprise me if 
this were the situation.

I’m not saying that this is the case, but merely to say that the Yes/No/IDK 
does not represent the full set of feasible responses.

Regards,

Neil

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 6:15:44 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 8:54 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > What the heck does it mean when sometimes you say you are posting "in a
> > personal capacity" and sometimes you don't?
> 
> 
> It sounds like you were very prescient in your inability to remember
> things, as you mentioned at
> https://groups.google.com/d/msg/mozilla.dev.security.policy/cCeLZuxAOvQ/iM1cbmxjDgAJ
> 
> Hope that helps explain how things work. I sometimes include it to help jog
> the memory of folk who tend to forget, so sorry that the extra reminder
> sounds like it might have confused you.
> 
> 
> > does GSB use any EV certificate identity data in its phishing algorithms.
> > My understanding is that the answer is yes,
> >
> 
> That's a good question, but I'm not sure where your understanding came
> from! I was hoping you could share more, since that would definitely be the
> easiest way to confirm it. It sounds like you're not sure, and you don't
> have any evidence handy. If you can find out more information, can you
> report back? It seems like you have some contacts or some information that
> led you to your conclusion, I'm sure there is no one more effective or
> efficient at finding an answer than you.
> 
> I've never heard of that, so of course, I wouldn't know where to start. On
> the other hand, if you're not sure, it might be clearer not to definitively
> state that's how things work, or presume they work? That might make it a
> bit clearer about what's real and what's imagined, in case you're just
> misremembering things. After all, if you don't know, and I don't know, and
> no one else here knows, maybe it's worth focusing on the things we do know
> instead of speculating?
> 
> The information I have about use of EV identity data for anti-phishing
> > algorithms was all provided in private communications, so I would not be
> > able to name any names without permission.  I have already emailed two
> > people about this,
> >
> 
> Great! Then it sounds like we're on track to having you report back once
> you know more. I look forward to hearing how they've solved this, as it
> sounds like EV might have be valuable even when the UI isn't shown. That
> would be great validation that you don't need to show prominent UI to get
> user benefit.

OK, I'll try one last time to see if you are willing to share Google 
information that you have with this group on the question at hand (Do browser 
phishing filters and anti-virus apps use EV data in their anti-phishing 
algorithms).  

This is super easy, and doesn't even require you to do any work, like 
contacting Google Safe Browsing and asking them to participate in this 
conversation.

Here's the question, and all I'm asking you to do is answer "Yes," "No," or "I 
Don't Know"

**Based on your personal knowledge, does Google Safe Browsing use any EV 
certificate Subject information in its anti-phishing algorithms?**

This will be useful information to everyone on this list.

Thanks for your cooperation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Leo Grove via dev-security-policy]

On Thursday, August 29, 2019 at 5:26:55 PM UTC-5, Kirk Hall wrote:
> On Thursday, August 29, 2019 at 3:10:49 PM UTC-7, Ryan Sleevi wrote:
> > On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > 
> > >
> > > Don't argue with me, argue with the browser phishing filters and
> > > anti-phishing services who do, in fact, use EV website information to
> > > protect users as I described.  Presumably they know what they are doing.
> > 
> > 
> > Sorry that it sounded like I'm arguing. I'm just trying to understand the
> > premise, since it so obviously has security holes that would make EV
> > certificates more dangerous for any user who relied on such services.
> > 
> > Could you point to the browsing phishing filters and anti-phishing services
> > that do? It might be an opportunity for you to find out how they deal with
> > this, and report back, so we don't have to presume anything.
> 
> Let's hear directly from the experts - can you get someone from Google Safe 
> Browsing to post to this list, and then we can all ask him or her our 
> questions and get the definitive answers.  Thanks.

Kirk,

What you are implying about GSB (and possibly other phishing filters) using the 
information contained within EV SSL certificates as part of their algorithm 
changes the reliance of EV SSL/TLS in fundamental ways.

The end result of removing the EV UI is that the decision to trust a website 
based on EV is practically transferred from the user to GSB and other phishing 
filters since the user cannot see the EV UI. The user is still impacted by the 
EV information depending on how GSB interprets it along with other signals. 

If GSB does factor in EV, I'm curious to learn how they use the jurisdiction 
information in the EV certificates as well as other information. Some posters 
on this thread advocate doing away with the EV UI due to issues discussed 
previously, but I wonder if they are aware that this information still might be 
used to block certain websites or influence the user's behavior without the 
user ever knowing that the EV information was used.

Will CAs market EV SSL as a way for sites to increase their "scores" with GSB 
and other phishing filters?


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

RE: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jeremy Rowley via dev-security-policy]

Is our answer right though? I wasn't sure. I said "Good" because "a promise to 
issue a cert" could be considered the same issued. In that case the BRs say you 
must respond good. However, if "a promise to issue a certificate" is not the 
same as issuance, the BRs don't apply to the OCSP until the certificate issues 
and the correct response is "Revoked" per the RFC. 

The BRs apply for sure to the contents, but do they apply to the OCSP responses 
in the time period between when the pre-cert is logged and the cert is signed. 

Seems like a nice simple rule is that the promise to issue is issuance 
regardless of what the BRs say and that you should respond good. This was our 
logic and why we decided on "Good". However, a very strict reading of the RFC 
and BR interaction means you need to respond "Revoked" until the cert issues. I 
don't like that outcome because it's complicated and leads to confusion. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Jacob Hoffman-Andrews via dev-security-policy
Sent: Thursday, August 29, 2019 5:37 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for 
Some Precertificates

Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652

On 2019.08.28 we read Apple’s bug report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
responder returning incorrect results for a precertificate. This prompted us to 
run our own investigation. We found in an initial review that for 35 of our 
precertificates, we were serving incorrect OCSP results (“unauthorized” instead 
of “good”). Like DigiCert, this happened when a precertificate was issued, but 
the corresponding certificate was not issued due to an error.

We’re taking these additional steps to ensure a robust fix:
  - For each precertificate issued according to our audit logs, verify that we 
are serving a corresponding OCSP response (if the precertificate is currently 
valid).
  - Configure alerting for the conditions that create this problem, so we can 
fix any instances that arise in the short term.
  - Deploy a code change to Boulder to ensure that we serve OCSP even if an 
error occurs after precertificate issuance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Kurt Roeckx via dev-security-policy]

On 2019-08-30 12:14, Jakob Bohm wrote:

On 30/08/2019 01:36, Jacob Hoffman-Andrews wrote:

Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652

On 2019.08.28 we read Apple’s bug report at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
responder returning incorrect results for a precertificate. This prompted us to 
run our own investigation. We found in an initial review that for 35 of our 
precertificates, we were serving incorrect OCSP results (“unauthorized” instead 
of “good”). Like DigiCert, this happened when a precertificate was issued, but 
the corresponding certificate was not issued due to an error.

We’re taking these additional steps to ensure a robust fix:
- For each precertificate issued according to our audit logs, verify that 
we are serving a corresponding OCSP response (if the precertificate is 
currently valid).
- Configure alerting for the conditions that create this problem, so we can 
fix any instances that arise in the short term.
- Deploy a code change to Boulder to ensure that we serve OCSP even if an 
error occurs after precertificate issuance.



For CAs affected by OCSP misbehavior in this particular scenario (Pre-
Cert issued and submitted to CT, actual cert not issued), they should
take a look at those error cases and subdivide them into:

1. No intent to actually issue the actual cert.  Best handling is to
   treat as revoked in all revocation protocols and logs, but with audit
   and incident systems reporting that the cert wasn't actually issued.
   ( *Most common case* ).

2. Intent to actually issue later, if/when something happens that just
   takes longer than usual.  Here it makes sense for OCSP and other such
   mechanisms to return "good", due to the ban on reporting "certificate
   hold" or otherwise exiting a revoked state.  It of cause remains
   possible to later revoke such a half-issued cert if there is a reason
   to do so.

3. Intent to issue in a few minutes, somehow OCSP was queried during the
   short processing delay between CT submission and actual issuing of
   cert with embedded CT proofs.  Because inserting the CT proofs in the
   OCSP responses probably awaits the same technical condition as the
   cert issuing, it makes sense to return "unknown" for those few
   minutes, as when delivery of the cert status to the OCSP servers is
   itself delayed by a few minutes (up to whatever limit policies set
   for updating revocation servers with knowledge of new certs).


It's not obvious for me why such cases exist, and I think it would at 
least be useful to have an actual list of why a pre-certificate was 
issued and the real certificate was not.


If the pre-certificate was issued, it means all validation should 
already have happened, and there is no reason not to issue the real 
certificate other than some problems preventing it. But the difference 
between 3) and 1) and 2) seems to be someone manually moved it from 3) 
to one of the other 2.


Examples of reasons for me are things like:
- There is some technical problem with a server, it will be issued when 
the server works again, or it's redirected to some other server. (like 
can't get enough SCTs.)

- You lint the pre certificate and see an issue (and should revoke it)

I think there shouldn't exist pre-certificates that are valid without 
the real certificate, after some delay. For instance, if you can't issue 
the real certificate within 24 hours, revoke the pre-certificate.



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

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Jakob Bohm via dev-security-policy]

On 30/08/2019 01:36, Jacob Hoffman-Andrews wrote:
> Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652
> 
> On 2019.08.28 we read Apple’s bug report at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP 
> responder returning incorrect results for a precertificate. This prompted us 
> to run our own investigation. We found in an initial review that for 35 of 
> our precertificates, we were serving incorrect OCSP results (“unauthorized” 
> instead of “good”). Like DigiCert, this happened when a precertificate was 
> issued, but the corresponding certificate was not issued due to an error.
> 
> We’re taking these additional steps to ensure a robust fix:
>- For each precertificate issued according to our audit logs, verify that 
> we are serving a corresponding OCSP response (if the precertificate is 
> currently valid).
>- Configure alerting for the conditions that create this problem, so we 
> can fix any instances that arise in the short term.
>- Deploy a code change to Boulder to ensure that we serve OCSP even if an 
> error occurs after precertificate issuance.
> 

For CAs affected by OCSP misbehavior in this particular scenario (Pre-
Cert issued and submitted to CT, actual cert not issued), they should 
take a look at those error cases and subdivide them into:

1. No intent to actually issue the actual cert.  Best handling is to 
  treat as revoked in all revocation protocols and logs, but with audit 
  and incident systems reporting that the cert wasn't actually issued.
  ( *Most common case* ).

2. Intent to actually issue later, if/when something happens that just 
  takes longer than usual.  Here it makes sense for OCSP and other such 
  mechanisms to return "good", due to the ban on reporting "certificate 
  hold" or otherwise exiting a revoked state.  It of cause remains 
  possible to later revoke such a half-issued cert if there is a reason 
  to do so.

3. Intent to issue in a few minutes, somehow OCSP was queried during the 
  short processing delay between CT submission and actual issuing of 
  cert with embedded CT proofs.  Because inserting the CT proofs in the 
  OCSP responses probably awaits the same technical condition as the 
  cert issuing, it makes sense to return "unknown" for those few 
  minutes, as when delivery of the cert status to the OCSP servers is 
  itself delayed by a few minutes (up to whatever limit policies set 
  for updating revocation servers with knowledge of new certs).

Scenario 2 can be subdivided in two sub-cases for compliance purposes:

2A: Pre-cert (and thus cert) has a "valid from" date equal or near the 
  CT submission time.  Here the CT logged pre-cert provides proof that 
  this is not backdating, even though cert usage won't start until 
  later.

2B: Pre-cert (and thus cert) has a "valid from" date closer to the 
  intended issuing date for the final cert.  Here the CT logged pre-cert 
  provides proof that certain issuance decisions happened earlier, thus 
  affecting when some of the validity time limits are reached.

Note that for some cert types (such as certs for S/MIME SubCAs), it is 
trivially possible for a subscriber to use the validity before the cert 
actually exists, while in other cases it is not possible, except for the 
difficulty in proving that the cert doesn't exist.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy