Re: Anomalous Certificate Issuances based on historic CAA records

[Ben Laurie via dev-security-policy]

On 29 November 2017 at 22:33, Paul Wouters <p...@nohats.ca> wrote:

>
>
> > On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > This whole conversation makes me wonder if CAA Transparency should be a
> > thing.
>
> That is a very hard problem, especially for non-DNSSEC signed ones.
>

Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear
chain of responsibility for keys, and that is relatively easy to build on.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Anomalous Certificate Issuances based on historic CAA records

[Ben Laurie via dev-security-policy]

This whole conversation makes me wonder if CAA Transparency should be a
thing.

On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The Thawte records aren't showing any CAA record preventing wildcards
> either.
>
> Here's the Thawte CAA record logs for the domain:
>
> 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Lookup domain: trnava-vuc.sk type: 257 result: 4 lookupTimeout: 500
> 2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Looking for alias for: trnava-vuc.sk
> 2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Lookup domain: trnava-vuc.sk type: 5 result: 4 lookupTimeout: 750
> 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk] :
> CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Time taken in seconds for CAA check of trnava-vuc.sk is: 1
> 2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - CAAResponse: CAAMatchCode : [32] : CAAInput : [*.trnava-vuc.sk] :
> CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Time taken in seconds for CAA check of *.trnava-vuc.sk is: 2
>
> Jeremy
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of
> douglas.beattie--- via dev-security-policy
> Sent: Wednesday, November 29, 2017 4:27 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Anomalous Certificate Issuances based on historic CAA records
>
> Hi Quirin,
>
> I'm curious about how you recorded the historical information from DNS,
> can you explain how this was requested and logged?
>
> We logged the data used for issuance of the GlobalSign certificate at the
> time of issuance and it's different from what you recorded.
>
> We logged that there was no “issuewild” entry and that "digicert.com", "
> globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as
> “issue” at time of issuance.
>
> Doug
>
> On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> > Hi Quirin,
> >
> > Thank you for your work on this topic. I would be grateful if you
> > could file Bugzilla bugs in the Misissuance component as follows,
> > giving your evidence of misissuance:
> >
> > On 22/11/17 23:50, Quirin Scheitle wrote:
> > > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > > Batch: https://clicktime.symantec.com/a/1/
> 4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_
> 82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_
> 74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-
> IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_
> 4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD
> 8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_
> 01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_
> 6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-
> D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SB
> e=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > > Description: best confer
> > > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fgroups.google
> > > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > > 1AAAJ
> >
> > One bug per CA, please.
> >
> > > 4) Apparent non-evaluation of CAA records
> > > Batch: https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--
> jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-
> CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgt
> uvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0Lh
> TmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__
> 1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHo
> xoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-
> J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4
> WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3C
> 

Re: GoDaddy Revocation Disclosure

[Ben Laurie via dev-security-policy]

On Fri, 17 Aug 2018 at 18:22, Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Revoke Disclosure
>
> GoDaddy has been proactively performing self-audits. As part of this
> process, we identified a vulnerability in our code that would allow our
> validation controls to be bypassed. This bug would allow for a Random Value
> that was generated for intended use with Method 3.2.2.4.6 and 3.2.2.4.7 and
> was validated using Method 3.2.2.4.2 by persons who were not confirmed as
> the domain contact. This bug was introduced November 2014 and was leveraged
> to issue a total of 865 certificates. The bug was closed hours after
> identification, and in parallel we started the scope and revocation
> activities.
>
> In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued
> certificates were revoked within 24 hours of identification.
>
> A timeline of the Events for Revocation are as follows:
>
> 8/13 9:30am – Exploit issue surfaced as possible revocation event.
> 8/13 9:30-4pm – Issue scope identification (at this point it was unknown),
> gathering certificate list
> 8/13 4pm – Certificate list finalized for revoke total 825 certs, Revoke
> notification sent to cert owners.
>

I presume you mean domain owners?

Do we know if any of these certs were used? If so, how?


> 8/14 1:30pm – All certificates revoked.
>
> Further research identified 40 certificates which contained re-use of
> suspect validation information.
> 8/15 – 2pm – Additional certificates identified due to re-use.
> 8/15 – 2:30pm – Customers notified of pending revoke.
> 8/16 – 12:30pm – All certificated revoked.
>
> We stand ready to answer any questions or concerns.
> Daymion
>
> Certificate list which can be found in CRT.sh:
>
> Domain,CRT.sh link
> www.makancoaching.co.uk,https://crt.sh/?id=486518293
> www.superguttervac.co.uk,https://crt.sh/?id=484345622
> www.aloftimaging.co.uk,https://crt.sh/?id=486443992
> www.inverroycrisismanagement.com,https://crt.sh/?id=505471354
> *.lumeter.co.uk,https://crt.sh/?id=575952063
> theredstartprimaryschool.co.uk,https://crt.sh/?id=448982417
> www.glscoatings.co.uk,https://crt.sh/?id=471607541
> www.thelittlecakekitchen.co.uk,https://crt.sh/?id=622887520
> bri-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445612142
> mel-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445611906
> syd-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445589055
> www.photislight.co.uk,https://crt.sh/?id=627260711
> sportsandplayconsulting.co.uk,https://crt.sh/?id=432887146
> *.mca.uk.net,https://crt.sh/?id=476788955
> www.underdogcoffee.co.uk,https://crt.sh/?id=445809844
> www.kiyoraspa.co.uk,https://crt.sh/?id=448128056
> www.kinesisclinic.co.uk,https://crt.sh/?id=444013056
> www.homegenies.co.uk,https://crt.sh/?id=490198693
> activemountaineering.co.uk,https://crt.sh/?id=452604481
> www.brightonshellfish.co.uk,https://crt.sh/?id=48433
> www.electroquip.co.uk,https://crt.sh/?id=454680891
> www.melbournederbyshire.co.uk,https://crt.sh/?id=459144464
> iih.org.uk,https://crt.sh/?id=452613519
> *.growhub.co.uk,https://crt.sh/?id=445804391
> www.weaversguesthouse.co.uk,https://crt.sh/?id=516764585
> *.ctc-solutions.co.uk,https://crt.sh/?id=508837605
> thothmail.saqqara.co.uk,https://crt.sh/?id=627917932
> www.ringwoodhallhotel.com,https://crt.sh/?id=456471228
> remote.yachtingpages.com,https://crt.sh/?id=453013515
> www.waynesecigsupplies.co.uk,https://crt.sh/?id=484348665
> www.thoth.saqqara.co.uk,https://crt.sh/?id=477514633
> remote.mara.uk.com,https://crt.sh/?id=491400207
> www.needfulthings.uk.com,https://crt.sh/?id=458812648
> www.sensoryapphouse.com,https://crt.sh/?id=460684499
> www.youcanbecome.co.uk,https://crt.sh/?id=486521955
> *.speechbuilder.co.uk,https://crt.sh/?id=465020837
> www.somerville-house.co.uk,https://crt.sh/?id=513011072
> www.cameoclassics.co.uk,https://crt.sh/?id=627503851
> praxis-godesberger-allee.de,https://crt.sh/?id=491408016
> www.hydra-te.co.uk,https://crt.sh/?id=505470107
> *.mca.uk.net,https://crt.sh/?id=476788955
> *.mhsserver5.com,https://crt.sh/?id=575963842
> www.dormagen-anwalt.de,https://crt.sh/?id=487910728
> rosenbaumgruppe.eu,https://crt.sh/?id=484075777
> remote.micheloud.net,https://crt.sh/?id=491387626
> webmail.janssensmarket.com,https://crt.sh/?id=527896643
> www.collegeinabox.co.uk,https://crt.sh/?id=500425581
> www.lepetitcapelier.com,https://crt.sh/?id=497736247
> www.total-michel.com,https://crt.sh/?id=486035156
> www.thetoolbox.uk.com,https://crt.sh/?id=486038438
> www.theinformer.org.uk,https://crt.sh/?id=488179681
> outlook.comprovide.de,https://crt.sh/?id=575914237
> www.vellastar.com,https://crt.sh/?id=493898204
> mail.iarg.com.au,https://crt.sh/?id=501369255
> www.iplacenotes.com,https://crt.sh/?id=487635287
> isiportalorders.com,https://crt.sh/?id=496718880
> www.ostsee-grundbesitz.de,https://crt.sh/?id=518520334
> invia-koeln.de,https://crt.sh/?id=489938629
> www.nikkihalliwell.com,https://crt.sh/?id=510581809
> 

Re: How do you handle mass revocation requests?

[Ben Laurie via dev-security-policy]

On 28 February 2018 at 19:40, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The end user agreed to the subscriber agreement, not Trustico. Our
> analysis follows what Peter B. posted – the subscriber is the “natural
> person or Legal Entity to whom a Certificate is issued and who is legally
> bound by a Subscriber Agreement or Terms of Use"—which in this case was
> Trustico’s customers.  In addition, we felt that given (1) the number of
> certificates Trustico was asking us to mass-revoke and (2) the lack of any
> substantiation of why Trustico thought the certs were “compromised,” we
> needed more information before revoking. At the minimum, it warranted
> alerting the contact for each certificate that revocation was imminent.
>
>
>
> I also agree that there’s no problem with the way or that the keys were
> provided to DigiCert for cert revocation.


Agree with who? Both asking for the keys and providing them seems weird to
me.

The more secure thing to do would be to ask for proof of possession of the
keys, e.g. by signing a random string with them...


> I certainly don’t want to discourage revocation of compromised certs!  My
> main question is how do you handle these things? The process at scale
> should not be different if a reseller requests revocation compared to any
> other security researcher. The question is how you handle the this volume
> of revocations when its happen? I’ve never received a revocation request of
> this magnitude before so I’m seeking the wisdom of the community in what we
> do.
>
>
>
> I’m happy to share any of the details I can.
>
>
>
> Jeremy
>
>
>
>
>
> From: Ryan Sleevi 
> Sent: Wednesday, February 28, 2018 11:58 AM
> To: Jeremy Rowley 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: How do you handle mass revocation requests?
>
>
>
>
>
>
>
> On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org  lists.mozilla.org> > wrote:
>
> On February 2nd, 2018, we received a request from Trustico to mass revoke
> all certificates that had been ordered by end users through Trustico.
> Unfortunately, the email was not sent to the appropriate certificate
> problem
> reporting channels and did not surface immediately so we're delayed in
> sharing the concerns and information. Once we were alerted, the team kicked
> off a debate that I wanted to bring to the CAB Forum. Basically, our
> position is that resellers do not constitute subscribers under the Baseline
> Requirement's definitions (Section 1.6.1). As such, we needed to confirm
> that either the key was compromised or that they revocation was authorized
> by the domain holder (the subscriber) prior to revoking the certificate.
> The
> certificates were not alleged as compromised at that time.
>
>
>
> I think there's a little nuance to this in the general case (e.g. consider
> "Resllers" who are also the hosting provider, and thus constitute the
> Applicant/Subscriber even when they're not the domain holder, but
> authorized by them), but based on this specific case, I think this sounds
> like a correct determination.
>
>
>
> I think the biggest question is who agreed to the terms - Trustico or the
> end-user - and that mostly impacts the rest of the decision here. Further,
> did Trustico warrant on behalf of the user that the user agreed to the
> terms (in which case, I would think it's a bit of a copout, and it's really
> Trustico agreeing, thus the Subscriber), or did DigiCert have direct
> communication with the user on the basis of Trustico's introduction (in
> which case, yeah, the Subscriber is the user)
>
>
>
> Anyway, just highlighting it here as perhaps not a uniform consensus, but
> perhaps not as material as what follows.
>
>
>
> On 2/27/2018, at my request for proof of compromise, we received a file
> with
> 23k private keys matched to specific Trustico customers. This definitely
> triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
> Once we received the keys, we confirmed that these were indeed the matching
> private keys for the reported certificates. We will be revoking these
> certificates today (February 28th, 2018).
>
>
>
> I think all of this sounds reasonable, no different than a security
> researcher (or random member of the public) who were to claim compromise
> with no evidence of that.
>
>
>
> Currently, we are only revoking the certificates if we received the private
> keys. There are additional certificates the reseller requested to have
> revoked, but DigiCert has decided to disregard that request until we
> receive
> proof of compromise or more information about the cause of this incident.
>
>
>
> For the same reason that "Jane Random User" should not be able to cause
> revocation merely by assertion, I think that sounds reasonable.
>
>
>
> This raises a question about the MDSP policy and 

Re: How do you handle mass revocation requests?

[Ben Laurie via dev-security-policy]

On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, 28 Feb 2018 20:03:51 +
> Jeremy Rowley via dev-security-policy
>  wrote:
>
> > The keys were emailed to me. I'm trying to get a project together
> > where we self-sign a cert with each of the keys and publish them.
> > That way there's evidence to the community of the compromise without
> > simply listing 23k private keys. Someone on Reddit suggested that,
> > which I really appreciated.
>
> That's probably me (tialaramex).
>
> Anyway, if it is me you're referring to, I suggested using the private
> keys to issue a bogus CSR. CSRs are signed, proving that whoever made
> them had the corresponding private key but they avoid the confusion
> that comes from DigiCert (or its employees) issuing bogus certs.
> Everybody reading m.d.s.policy can still see that a self-signed cert is
> harmless and not an attack, but it may be harder to explain in a
> soundbite. Maybe more technically able contributors disagree ?
>

Seems to me that signing something that has nothing to do with certs is a
safer option - e.g. sign random string+Subject DN.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 16:41, Ryan Sleevi  wrote:

>
>
> On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie  wrote:
>
>>
>>
>> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> I believe that may be misunderstanding the concern.
>>>
>>> Once these certificates expire, there's not a good way to check whether
>>> or
>>> not they were revoked, because such revocation information may be culled
>>> after certificate expiration.
>>>
>>> Similarly, if one is looking to verify the claims about revocation dates
>>> and timelines, once those are culled from the CRLs, you can only
>>> demonstrate with past CRLs or responses that may have been archived.
>>>
>>> The concern about December 6 represents when some of the certificates
>>> begin
>>> to expire, and thus being able to examine whether or not and when things
>>> were done may no longer be available.
>>>
>>
>> This is one of the reasons we also need revocation transparency.
>>
>
> As tempting as the buzzword is, and as much as we love motherhood and
> apple pie and must constantly think of the children, slapping transparency
> after a word doesn't actually address the needs of the community or users,
> nor does it resolve the challenging policy issues that arise. Just because
> something is cryptographically verifiable does not mean it actually
> resolves real world problems, or does not introduce additional ones.
>
> A simpler solution, for example, is to maintain an archive of CRLs signed
> by the CA. Which would address the need without the distraction, and
> without having the technical equivalent of Fermat's Last Theorem being
> invoked. Let's not let the perfect (and unspecified) be the enemy of the
> good and reasonable.
>

I am, of course, not opposed to such archives, but the core reason
"transparency" is an improvement is that it practically and efficiently
prevents equivocation, which archives do not.

Perhaps you don't care about equivocation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 19:01, Rob Stradling  wrote:

> On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
> > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie  wrote:
> 
> >> This is one of the reasons we also need revocation transparency.
> >
> > As tempting as the buzzword is, and as much as we love motherhood and
> apple
> > pie and must constantly think of the children, slapping transparency
> after
> > a word doesn't actually address the needs of the community or users, nor
> > does it resolve the challenging policy issues that arise. Just because
> > something is cryptographically verifiable does not mean it actually
> > resolves real world problems, or does not introduce additional ones.
> >
> > A simpler solution, for example, is to maintain an archive of CRLs signed
> > by the CA. Which would address the need without the distraction, and
> > without having the technical equivalent of Fermat's Last Theorem being
> > invoked. Let's not let the perfect (and unspecified) be the enemy of the
> > good and reasonable.
>
> FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever
> signed.
>

Put it in Trillian? :-)


>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I believe that may be misunderstanding the concern.
>
> Once these certificates expire, there's not a good way to check whether or
> not they were revoked, because such revocation information may be culled
> after certificate expiration.
>
> Similarly, if one is looking to verify the claims about revocation dates
> and timelines, once those are culled from the CRLs, you can only
> demonstrate with past CRLs or responses that may have been archived.
>
> The concern about December 6 represents when some of the certificates begin
> to expire, and thus being able to examine whether or not and when things
> were done may no longer be available.
>

This is one of the reasons we also need revocation transparency.


>
> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Thu, Oct 11, 2018 at 11:19:18PM +, please please via
> > dev-security-policy wrote:
> > > I was under the impression that CAs were allowed to remove CRL entries
> > and OCSP support for expired certificates for some reason. Good to know!
> >
> > CT logs are not CRLs or OCSP responders, nor do they track revocation.
> >
> > - Matt
> >
> > ___
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 13:54, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 12/10/2018 14:33, Ben Laurie wrote:
> > On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> I believe that may be misunderstanding the concern.
> >>
> >> Once these certificates expire, there's not a good way to check whether
> or
> >> not they were revoked, because such revocation information may be culled
> >> after certificate expiration.
> >>
> >> Similarly, if one is looking to verify the claims about revocation dates
> >> and timelines, once those are culled from the CRLs, you can only
> >> demonstrate with past CRLs or responses that may have been archived.
> >>
> >> The concern about December 6 represents when some of the certificates
> begin
> >> to expire, and thus being able to examine whether or not and when things
> >> were done may no longer be available.
> >>
> >
> > This is one of the reasons we also need revocation transparency.
> >
>
> Or just a crt.sh enhancement to remember the previously collected
> revocations.
>
> Unlike certificates, revocations are already published in signed CRLs
> that auditing services can simply gather and store, along with some
> timestamping of the fact that they were seen at a given time.
>
> The exception being Let's Encrypt, because they only provide OCSP.
>
> A secondary auditing process can statistically sample certificates
> from CRLs and CT and check that the samples have the published OCSP
> response, plus/minus an acceptable delay (policy dictated) between
> updating of OCSP and CRL servers.
>

Of course this is also useful. Transparency, however, would prevent certain
attacks that this does not.


>
> >
> >>
> >> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >>> On Thu, Oct 11, 2018 at 11:19:18PM +, please please via
> >>> dev-security-policy wrote:
>  I was under the impression that CAs were allowed to remove CRL entries
> >>> and OCSP support for expired certificates for some reason. Good to
> know!
> >>>
> >>> CT logs are not CRLs or OCSP responders, nor do they track revocation.
> >>>
> >>> - Matt
> >>>
>
>
>
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 19 Oct 2018 at 10:38, Rob Stradling  wrote:

> On 18/10/2018 22:55, Ben Laurie wrote:
> > On Fri, 12 Oct 2018 at 19:01, Rob Stradling wrote:
> >
> > On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
> >  > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie  > > wrote:
> > 
> >  >> This is one of the reasons we also need revocation transparency.
> >  >
> >  > As tempting as the buzzword is, and as much as we love motherhood
> > and apple
> >  > pie and must constantly think of the children, slapping
> > transparency after
> >  > a word doesn't actually address the needs of the community or
> > users, nor
> >  > does it resolve the challenging policy issues that arise. Just
> > because
> >  > something is cryptographically verifiable does not mean it
> actually
> >  > resolves real world problems, or does not introduce additional
> ones.
> >  >
> >  > A simpler solution, for example, is to maintain an archive of
> > CRLs signed
> >  > by the CA. Which would address the need without the distraction,
> and
> >  > without having the technical equivalent of Fermat's Last Theorem
> > being
> >  > invoked. Let's not let the perfect (and unspecified) be the enemy
> > of the
> >  > good and reasonable.
> >
> > FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've
> ever
> > signed.
> >
> >
> > Put it in Trillian? :-)
>
> That had occurred to me.  ;-)
>
> Would it be useful?
>

To be properly useful you would need to extend CRL protocols to include
inclusion proofs, but its a step in the right direction. Is there a way to
add ad-hoc stuff to CRLs?


>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Laurie via dev-security-policy]

On Fri, 16 Aug 2019 at 14:31, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> DB: Yes, that's true.  I was saying that phishing sites don't use EV, not
> that EV sites don't get phished

Surely this shows that EV is not needed to make phishing work, not that EV
reduces phishing?



-- 
I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

https://g.co/u58vjr https://g.co/adjusu
*(Google internal)*
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ben Laurie via dev-security-policy]

On Mon, 2 Dec 2019 at 20:28, Wayne Thayer  wrote:

> Why not "AIA chasing considered harmful"? The current state of affairs is
> that most browsers [other than Firefox] will go and fetch the intermediate
> if it's not cached. This manifests itself as sites not working in Firefox,
> and users switching to other browsers.
>

AIA does not prevent single verifications from working, unlike caching.


>
> You may be further dismayed to learn that Firefox will soon implement
> intermediate preloading [1] as a privacy-preserving alternative to AIA
> chasing.
>

If that involves loading and using intermediates that are not actually
available via AIA, then yes.


> - Wayne
>
> [1]
> https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading#Intermediate_CA_Preloading
>
> On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie  wrote:
>
>>
>>
>> On Thu, 28 Nov 2019 at 20:22, Peter Gutmann 
>> wrote:
>>
>>> Ben Laurie via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> writes:
>>>
>>> >In short: caching considered harmful.
>>>
>>> Or "cacheing considered necessary to make things work"?
>>
>>
>> If you happen to visit a bazillion sites a day.
>>
>>
>>> In particular:
>>>
>>> >caching them and filling in missing ones means that failure to present
>>> >correct cert chains is common behaviour.
>>>
>>> Which came first?  Was cacheing a response to broken chains or broken
>>> chains a
>>> response to cacheing?
>>>
>>> Just trying to sort out cause and effect.
>>>
>>
>> Pretty sure if broken chains caused browsers to not show pages, then
>> there wouldn't be broken chains.
>>
>> --
>> I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
>> #VerifyAllTheThings.
>>
>> https://g.co/u58vjr https://g.co/adjusu
>> *(Google internal)*
>>
>

-- 
I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

https://g.co/u58vjr https://g.co/adjusu
*(Google internal)*
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ben Laurie via dev-security-policy]

On Wed, 4 Dec 2019 at 22:13, Ryan Sleevi  wrote:

> Yes, I am one of the ones who actively disputes the notion that AIA
> considered harmful.
>
> I'm (plesantly) surprised that any CA would be opposed to AIA (i.e.
> supportive of "considered harmful", since it's inherently what gives them
> the flexibility to make their many design mistakes in their PKI and still
> have certificates work. The only way "considered harmful" would work is if
> we actively remove the flexibility afforded CAs in this realm, which I'm
> highly supportive of, but which definitely encourages more distinctive PKIs
> (i.e. more explicitly reducing the use of Web PKI in non-Web cases)
>
> Of course, AIA is also valuable in helping browsers push the web forward,
> so I can see why "considered harmful" is useful, especially in that it
> helps further the notion that root certificates are a thing of value (and
> whose value should increase with age). AIA is one of the key tools to
> helping prevent that, which we know is key to ensuring a more flexible, and
> agile, ecosystem.
>
> The flaw, of course, in a "considered harmful", is the notion that there's
> One Chain or One Right Chain. That's not the world we have, nor have we
> ever. The notion that there's One Right Chain for a TLS server to send
> presumes there's One Right Set of CA Trust Anchors. And while that's
> definitely a world we could pursue, I think we know from the past history
> of CA incidents, there's incredible benefit to users to being able to
> respond to CA security incidents differently, to remove trust in
> deprecated/insecure things differently, and to set policies differently.
> And so we can't expect servers to know the Right Chain because there isn't
> One Right Chain, and AIA (or intermediate preloading with rapid updates)
> can help address that.
>

It would be a whole lot more efficient and private if the servers did the
chasing.


>
> On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Someone really should write up "AIA chasing considered harmful".  It was
>> disputed at the TLS session at IETF 105, which shows that the reasoning
>> behind it is not as widely understood as it needs to be, even among TLS
>> experts.
>>
>> I'm very appreciative of Firefox's efforts in this area.  Leveraging the
>> knowledge of all the publicly disclosed ICAs to improve chain-building is
>> an
>> idea whose time has come.
>>
>> -Tim
>>
>> > -Original Message-
>> > From: dev-security-policy <
>> dev-security-policy-boun...@lists.mozilla.org>
>> On
>> > Behalf Of Wayne Thayer via dev-security-policy
>> > Sent: Monday, December 2, 2019 3:29 PM
>> > To: Ben Laurie 
>> > Cc: mozilla-dev-security-policy
>> ;
>> > Peter Gutmann 
>> > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox
>> >
>> > Why not "AIA chasing considered harmful"? The current state of affairs
>> is
>> that
>> > most browsers [other than Firefox] will go and fetch the intermediate if
>> it's not
>> > cached. This manifests itself as sites not working in Firefox, and users
>> switching
>> > to other browsers.
>> >
>> > You may be further dismayed to learn that Firefox will soon implement
>> > intermediate preloading [1] as a privacy-preserving alternative to AIA
>> chasing.
>> >
>> > - Wayne
>> >
>> > [1]
>> >
>>
>> https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading
>> > #Intermediate_CA_Preloading
>> >
>> > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie  wrote:
>> >
>> > >
>> > >
>> > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann
>> > > 
>> > > wrote:
>> > >
>> > >> Ben Laurie via dev-security-policy
>> > >> 
>> > >> writes:
>> > >>
>> > >> >In short: caching considered harmful.
>> > >>
>> > >> Or "cacheing considered necessary to make things work"?
>> > >
>> > >
>> > > If you happen to visit a bazillion sites a day.
>> > >
>> > >
>> > >> In particular:
>> > >>
>> > >> >caching them and filling in missing ones means that failure to
>> > >> >present correct cert chains is common behaviour.
>> > >>
>> > >> Which came first?  Was cachei

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ben Laurie via dev-security-policy]

On Thu, 28 Nov 2019 at 20:22, Peter Gutmann 
wrote:

> Ben Laurie via dev-security-policy 
> writes:
>
> >In short: caching considered harmful.
>
> Or "cacheing considered necessary to make things work"?


If you happen to visit a bazillion sites a day.


> In particular:
>
> >caching them and filling in missing ones means that failure to present
> >correct cert chains is common behaviour.
>
> Which came first?  Was cacheing a response to broken chains or broken
> chains a
> response to cacheing?
>
> Just trying to sort out cause and effect.
>

Pretty sure if broken chains caused browsers to not show pages, then there
wouldn't be broken chains.

-- 
I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

https://g.co/u58vjr https://g.co/adjusu
*(Google internal)*
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: How Certificates are Verified by Firefox

[Ben Laurie via dev-security-policy]

One of the things that was quite annoying when developing CT was browser
behaviour wrt intermediates - caching them and filling in missing ones
means that failure to present correct cert chains is common behaviour.
Which means that anything that _doesn't_ see a lot of certs has quite a low
chance of actually verifying a random EE cert.

Indeed this is so common that on the few occasions I've attempted to report
the bug I've been met with complete incomprehension.

Presumably this is one of the reasons many people switch off cert
validation. And then we wag our fingers and shake our heads at their
"stupidity".

In short: caching considered harmful.


On Wed, 20 Nov 2019 at 00:11, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> If you are one of the many people who have wondered how exactly Firefox
> handles some aspect of certificate processing, you may be interested to
> know that we have recently updated the information on our wiki:
>
> https://wiki.mozilla.org/SecurityEngineering/Certificate_Verification
>
> I hope you find this helpful.
>
> - Wayne
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

https://g.co/u58vjr https://g.co/adjusu
*(Google internal)*
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy