CRL/OCSP on IPv6-only networks

[sjw--- via dev-security-policy]

Hi,

While I was connected to an IPv6-only network I noticed, that some CAs
(e.g. Amazon, DigiCert, GoDaddy, QuoVadis) do not provide IPv6 on their
CRL and OCSP endpoints. This means that certificate revocation does not
work if you have no IPv6 or, depending on your security policy (e.g.
require valid OCSP response), you get a lot of false positives.

Currently there is no section in the CA BR that requires dual-stack for
CRL/OCSP. However, IPv6-only environments do exist and they will
increase in future. So I wonder if you're aware of this issue and if
there are any plans for mitigation.

Best regards,



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google OCSP service down

[sjw--- via dev-security-policy]

Hi

Thanks for investigating.

First of all, my previously curl command is not suitable to verify a
OCSP status. It only works for OCSP stapling which is not supported by
Google servers.
You may use openssl ocsp instead:
openssl ocsp -issuer [GoogleInternetAuthorityG2.crt] -cert
[googlecom.crt] -url http://clients1.google.com/ocsp -resp_text -header
HOST=clients1.google.com

I can confirm that the service is now working again for me most of the
time, but some queries still fail (may be due load balancing in the
backend?).


Am 21.01.2018 um 22:00 schrieb Hanno Böck via dev-security-policy:
> If I goole for that I end up at https://pki.google.com/ This page has
> a similar style as the pki.goog, but notably it doesn't list any
> contact info. It has an FAQ, but that doesn't have any question of the
> form "How do I report a problem with your CA?" The only thing that
> might be helpful is a pointer to report security incidents. I'd
> probably have done that, though I would be unsure, as it's debatable
> whether an offline OCSP counts as a security issue.

I ended up with the same situation. But "OCSP is down" does not fit in
any category on the vulnerability report site and the cartegory "other"
does only provide support articles.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Google OCSP service down

[sjw--- via dev-security-policy]

Hi

Google delivers the certificate [1] to me, for *.google.com,
*.youtube.com and other major services.
However, the OCSP service [2] does not work for me. I verified this from
multiple locations, machines, OSes and versions of Firefox. Furthermore,
I used SSL Labs [3] and the status on crt.sh [1] to verify. AFAIK other
browsers don't support hard fail for OCSP at all. However curl does:

$ curl --version
curl 7.57.0 (x86_64-pc-linux-gnu) libcurl/7.57.0 OpenSSL/1.1.0g
zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) libssh2/1.8.0
nghttp2/1.29.0
Release-Date: 2017-11-29
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s
rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM
NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
$ curl --cert-status https://www.google.com
curl: (91) No OCSP response received

I monitor this issue for some hours, but it's quite surprising that
Google has not yet fixed it. The OCSP service is not listed on their app
status board [4] and I failed to find any way to contact Google directly
about this issue. The Google PKI does not fit in any contact form I
found and the category "other" is always referring to some FAQs or similar.
It's also a single point of failure since all Google services are signed
by the Google PKI, which (if you are strict) cannot be fully trusted
without a valid OCSP response...

Can somebody confirm this issue? You can easily flip the
"security.OCSP.require" pref to true in about:config (Firefox) to check
or using curl.
Is there a known contact to report it (or is someone with a Google hat
reading this anyway)?
Is there any plan if a CA fails for whatever reason and cannot be
contacted anymore, because all their services are signed by themselves?
In the case of Google they are also preloaded and pinned in all (modern)
browsers, so it's very hard to bypass (for good reasons) if they would
have a serious issue in the PKI.



[1] https://crt.sh/?id=299058714=ocsp
[2] http://clients1.google.com/ocsp
[3]
https://www.ssllabs.com/ssltest/analyze.html?d=google.com=2607%3af8b0%3a4005%3a80a%3a0%3a0%3a0%3a200e
[4] https://www.google.com/appsstatus



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Apple's Further Steps for WoSign

[sjw]

Hi

Does this also affect the root CA of StartCom Class 4 (EV) and Class 3
(OV) certs?

Regards,
Jonas



Am 30.11.2016 um 21:32 schrieb
certificate-authority-prog...@group.apple.com:
> We are taking further actions to protect users in an upcoming security 
> update.  Apple products will block certificates from WoSign and StartCom root 
> CAs if the "Not Before" date is on or after 1 Dec 2016 00:00:00 GMT/UTC.




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Comodo issued a certificate for an extension

[sjw]

The affected cert has been logged here: https://crt.sh/?id=34242572


Am 24.09.2016 um 02:33 schrieb Richard Wang:
> First, I must make declaration that I don't know "Showfom", and I don't know 
> if he/she is a WoSign customer.
>
> As I said in my final statement that I wish all Mozilla trusted CA can post 
> their issued certificate to CT log server for full transparency, I am sure 
> not WoSign mis-issued certificate only, maybe some CA have more serious 
> problems.
>
> I paste my statement again here:
> WoSign believes that the Certificate Transparency is a very good solution for 
> self-discipline that force employees to attach great importance to product 
> quality control, and for external oversight mechanism that let the third 
> party supervise the CA's activity. 
> WoSign is the first CA that volunteer to post all issued SSL Certificates to 
> Google CT log server initiatively. Our aim is to let the worldwide users 
> trust WoSign SSL certificates, and hope to drive the global CAs to be open 
> and transparent publishing all issued certificates to CT log server, making 
> worldwide users, browser vendors and related stakeholder to take an overall 
> supervision, this will benefit the global Internet security.
>
>
> @Showfom: you don't need to say " Sorry for my bad English", your English is 
> very good! Our native language is Chinese, not English, so no need to say 
> sorry, I NEVER say this word again.
>
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Showfom
> Sent: Saturday, September 24, 2016 2:30 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Comodo issued a certificate for an extension
>
> First, let me introduce myself, I'm a famous investor of ccTLD domains from 
> China.
>
> Recently we get an easy-remember domain www.sb, please note the extension is 
> .sb
>
> I ordered a Comodo Positive SSL for this domain, the common name which I 
> submit is www.sb
>
> Usually they will give us a certificate for www.sb and www.www.sb, but this 
> time Comodo issues a certificate with DNS name www.sb and sb
>
> I can't find our certificate in crt.sh but can be viewed here
>
> https://censys.io/certificates/719c282a51e935051e88bf6115dda0731da21c0e12c08e6bcea36078e83e4966
>
> Or you can simply type https://www.sb/ in your browser to view the certificate
>
> https://www.sb/uploads/images/201609/24/181/n9k4qfbVYj.png
>
> I also tried to make an nginx conf in my server for https://sb/ you can 
> change your /etc/hosts or just use curl commmand
>
> curl -v -H "Host: sb" https://www.sb/
>
> You can find 403 Forbidden in title without any SSL certificate error because 
> I set the return status for https://sb/ to 403
>
> Sorry for my bad English
>
> Best Regards,
> @Showfom
> ___
> 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




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Is Firefox SHA-1 Deprecation Policy configurable?

[sjw]

I think that's the security.pki.sha1_enforcement_level pref [1][2].

Regards,
Jonas


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=942515#c35
[2]
https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/



Am 16.09.2016 um 16:53 schrieb therickf...@gmail.com:
> Working with a client on "workarounds" for avoiding SHA-1 deprecation on a 
> system they are woefully behind on updating for SHA-256 compatible.  They 
> asked/stated that Chrome & probably Firefox were "configurable" in regards to 
> shutting out the trust for SHA-1 SSL/TLS certs. I'm skeptical as I haven't 
> seen anything like that.   
>
> Is there any configurability in Firefox regarding this (e.g. from a GPO 
> perspective - Windows environment), or is all the SHA-1 deprecation policy 
> embedded in the Firefox code - to be enforced when that update is pushed out 
> (presumably on/around 1/1/17)? Thanks
>
> Rick
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[sjw]

Of course, adding the affected certs to OneCRL should be done immediately.

WoSign also has to be transparent about all (mis) issued certs in the
past and have to provide this info in the future.
If they can't, I think we may consider if the current certs that are
valid for 3 years should be restricted to a shorter period.

Regards,
Jonas


> For the thread's reference, here's the crt.sh link for the misissued GitHub
> certificate:
>
> https://crt.sh/?id=29647048
>
> Valid for 3 years, for github.com. It's not in OneCRL, CRLset, or
> Microsoft's disallowedcert.stl.
>
>
>
> On Wed, Aug 24, 2016 at 9:08 AM, Gervase Markham  wrote:
>
>> Taking into account all these incidents and the actions of this CA,
>> Mozilla is considering what action to take. Your input is welcomed.





signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: What is the dates planned for the SHA-1 Deprecation Plan for Firefox

[sjw]

Hi

As far as I know we have the following status:

> Add a security warning to the Web Console to remind developers that
they should not be using a SHA-1 based certificates
Has already been fixed. But currently SHA-1 is only exposed in the
console, not on the lock icon so far.

> Show the “Untrusted Connection” error whenever a SHA-1 certificate
issued after January 1, 2016, is encountered in Firefox
Has been fixed and reverted. Not shipped so far (see
security.pki.sha1_enforcement_level).

> Show the “Untrusted Connection” error whenever a SHA-1 certificate is
encountered in Firefox after January 1, 2017
Has not been fixed so far, but can be enabled (see
security.pki.sha1_enforcement_level).

There was also a discussion about exposing/untrust SHA-1 certs that
expires after January 1, 2017 (see https://sha1-2017.badssl.com/).


See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=942515
https://bugzilla.mozilla.org/show_bug.cgi?id=1183718
https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/


Regards,
Jonas


Am 17.06.2016 um 14:46 schrieb Jakob Bohm:
> On 06/06/2016 23:14, jjo...@mozilla.com wrote:
>> On Thursday, May 19, 2016 at 9:09:58 AM UTC-7, tal...@gmail.com wrote:
>>> Could you confirm the dates from which FF will be rejecting SHA-1
>>> SSL certificates (regardless of when they were issued)
>>
>> Hi Ajuram,
>>
>> I can't speak for Richard, but I do not believe there is a firm date
>> for rejecting all SHA-1 certs yet: The plan is still Q1 2017.
>>
>> I don't imagine we'd move earlier than that unless new research on
>> SHA-1 collisions prompts it.
>>
>> J.C.
>>
>
> One major suggestion (based on past experience with Chrome doing it
> wrong): Do not apply SHA-1 rejection to any of the following:
>
> 1. The self-signature on the root cert in a chain.
>
> 2. Cross-signatures/certs on a subject/public key combination which is
> also present as a trusted root in its own right (example: GlobalSign
> has long ago issued a cross-certificate where their old SHA-1 root cert
> SHA-1 signed their new SHA-2 root).
>
> 3. Any situation where the server / e-mail signer / code signer
> provides enough certs to form multiple trust chains and at least one
> trusted chain can be formed by ignoring all the non-root SHA-1 certs
> (this actually encompass cases 1 and 2 as special cases).
>
> 4. For file formats that can be signed with multiple certificates,
> accept the good signature and ignore any SHA-1 signatures that might be
> included for backward compatibility.  This includes: Anything with a
> PKCS#7/CMS signature (supports a "SET of SignerInfo"), Anything with
> JAR style signatures (including .xpi files, the JAR signature format
> spec allows an almost unlimited number of signature files in the .zip,
> each of which is a PKCS#7/CMS signature itself), anything with
> Microsoft Authenticode signatures (these are PKCS#7 but also allow
> additional signatures in a special unauthenticated signature attribute).
>
> By not rejecting these cases, servers/signers can provide alternative
> signature chains that are trusted by older clients.  For instance this
> could be a good thing to to for the "download Firefox" page, since
> people are likely to visit that using a woefully outdated browser.
>
> Enjoy
>
> Jakob




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

StartCom (false) vulnerability report

[sjw]

JFYI:
https://oalmanna.blogspot.com/2016/03/startssl-domain-validation.html
https://startssl.com/NewsDetails?date=20160322
https://startssl.com/NewsDetails?date=20160323

Regards,
Jonas



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update: section 8 of Maintenance Policy

[sjw]

I would like to see SHA-3 signatures and Ed25519/curve25519 ASAP.
The later one is not that far away [1].
Maybe it's the right time to consider them?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=957105


Am 05.11.2015 um 19:46 schrieb Kathleen Wilson:
> The next two topics to discuss [1] have to do with section 8 of
> Mozilla’s CA Certificate Maintenance Policy.
>
> The proposals are:
> - (D15) Deprecate SHA-1 Hash Algorithms in certs.
> and
> - (D4) In item #8 of the Maintenance Policy recommend that CAs avoid
> SHA-512 and P-521, especially in their CA certificates. This is to
> ensure interoperability, as SHA-512 and (especially) P-521 are less
> well-supported than the other algorithms. (Note: On the page you
> linked to, P-521 is incorrectly spelled "P-512".)
> -- Not sure if we should make this change...
>
> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1129083 was filed to
> remove support for certs signed using SHA-512-based signatures, but it
> was closed as invalid, and SHA-512 support was fixed via
> https://bugzilla.mozilla.org/show_bug.cgi?id=1155932
>
> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1129077 was filed to
> remove support for certs that use the P-521 curve. But this is still
> up for discussion.
>
> So, do we really want to add a comment to Mozilla's policy about
> limited support for SHA-512 and P-521?
>
> Here's what Mozilla's policy currently says:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
>
> ~~
> 8. We consider the following algorithms and key sizes to be acceptable
> and supported in Mozilla products:
> - SHA-1 (until a practical collision attack against SHA-1 certificates
> is imminent);
> - SHA-256, SHA-384, SHA-512;
> - Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over
> SECG and NIST named curves P-256, P-384, and P-512;
> - RSA 2048 bits or higher; and
> - RSA 1024 bits (only until December 31, 2013).
> ~~
>
> I recommend that we change it to the following:
> ~~
> 8. We consider the following algorithms and key sizes to be acceptable
> and supported in Mozilla products:
> - SHA-256, SHA-384, SHA-512;
> - Elliptic Curve Digital Signature Algorithm (using ANSI X9.62) over
> SECG and NIST named curves P-256, P-384, and P-521; and
> - RSA 2048 bits or higher.
> ~~
>
> Another option is to delete this section from Mozilla's policy,
> because it is covered by the Baseline Requirements. However, the
> Baseline Requirements allows for DSA, which Mozilla does not support.
> The “Key Sizes” section of the Baseline Requirements allows for:
> SHA‐256, SHA‐384 or SHA‐512
> NIST P‐256, P‐384, or P‐521
> DSA L= 2048, N= 224 or L= 2048, N= 256
>
>
> As always, I will appreciate your thoughtful and constructive input
> into this discussion.
>
> Kathleen
>
> [1]
> https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_That_Need_To_Be_Discussed
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[sjw]

Yes, some hosts are pinned:
https://dxr.mozilla.org/mozilla-central/source/security/manager/tools/PreloadedHPKPins.json

MITM is *always* bad and breaks the web. Modern browsers, especially
Firefox, have great features to protect the users and this is something
good. I'm pretty sure your students don't even know, that you attack
their connection to the Internet.
You may have no influence on the decision why you have to do this
(mostly because of surveillance and censorship), but this a political
discussion and there are many issues on this topic. I have no wish to
comment this further.


Am 16.09.2015 um 23:57 schrieb Kurt Roeckx:
> On Wed, Sep 16, 2015 at 02:51:28PM -0700, AnilG wrote:
>> there's another issue blocking them for Firefox: Secure Connection Failed. 
>> The connection to wiki.mozilla.org was interrupted while the page was 
>> loading.
> I wonder if firefox is using certificate pinning for
> *.mozilla.org.
>
>
> Kurt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FOITT does no longer support OCSP

[sjw]

Thank you!

Please inform me if you were successful.

Regards,
Jonas


Am 06.02.2015 um 16:43 schrieb Medin, Steven:
 I will contact the Swiss BIT and discuss.

 Kind regards,
 Steven Medin
 Product Manager, Identity and Access Management
 Verizon Enterprise Solutions
  

 -Original Message-
 From: dev-security-policy
 [mailto:dev-security-policy-bounces+steve.medin=verizonbusiness@lists.mo
 zilla.org] On Behalf Of Rob Stradling
 Sent: Friday, February 06, 2015 10:32 AM
 To: Richard Barnes; s...@gmx.ch
 Cc: mozilla-dev-security-pol...@lists.mozilla.org
 Subject: Re: FOITT does no longer support OCSP

 On 06/02/15 15:00, Richard Barnes wrote:
 Does the FOITT cert chain up to one of the roots in the Mozilla program?

 https://wiki.mozilla.org/CA:IncludedCAs

 I only see 3 Swisscom roots and 3 SwissSign roots, nothing that is 
 obviously Swiss government.
 This intermediate CA cert for Swiss Government SSL CA 01 was issued by the
 Baltimore CyberTrust Root built-in root.

 -BEGIN CERTIFICATE-
 MIIGKDCCBRCgAwIBAgIEBye2CTANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ
 RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD
 VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE0MDkxMDE4NTAzNloX
 DTE3MDkxMDE4NTAxMVowgYgxCzAJBgNVBAYTAkNIMR0wGwYDVQQKExRTd2lzcyBH
 b3Zlcm5tZW50IFBLSTERMA8GA1UECxMIU2VydmljZXMxIjAgBgNVBAsTGUNlcnRp
 ZmljYXRpb24gQXV0aG9yaXRpZXMxIzAhBgNVBAMTGlN3aXNzIEdvdmVybm1lbnQg
 U1NMIENBIDAxMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA379210+W
 I6Wl63BOe93KXb9T6mw4frXZBPgN6iKcVp4KGTOHLtCfztUrFJWWhNaapDoYcZKJ
 F4vNwQsYFIPZDdYhNeaubsOsoKznei3+1PBLpNyAVTbQ2SgEZcDuVYkpoSUzu+cT
 sZ/gAKYf3K1JacCdeEYRv55FXLJ991lTvKHLNNr4+IEZuOwMCqjdMKg/JF2Lh+nm
 AoT2YoUFBJHYWNMyTUZZ4pZVB8PZPCeM76FJHf+zG+kQ2gQhDaEyMFqjuH7URRkj
 nnV6GvenzOO7uIPiigKf9Ccpt05gnuezPKGtOwzJhpjTqOfxuVSH5HhDzDGPcrce
 rfwtHRW6Rnq0ix1kHUAmC6tB6fhKwCOOnSZ04YmaKwtMsGMsEIoaZ6+h7VlllKJ/
 OpVGGmTEdPzaEuJnCPUq0BuVOPWHtSyr6UcrTw4p8C+yjbE8Y99b9VkxdGGPU3vs
 8ZSObJjEILcR3NnQhK4/V9bP6v9CVqh933W/Q7LdN6vjWr6VdwqYUn1q7USqIp2W
 p+Q7KFg1VHh0JJTAirI9PSmsVmiWv4MXdBKFmd2PaT3w/HBEDTM5Fg8w6T0IPd26
 ApQ+Yg+EAkC+GfH0JNcVR3LdnVgm/IncnNJPrq7gteN1FJ+lxsbeN0947nDpoasf
 qjCUZVNcbzjeIfJEuBxZ6tCwJnrQF6Xi55UCAwEAAaOCAcUwggHBMBIGA1UdEwEB
 /wQIMAYBAf8CAQAwgakGA1UdIASBoTCBnjBIBgkrBgEEAbE+AQAwOzA5BggrBgEF
 BQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnku
 Y2ZtMFIGCGCFdAERAxUCMEYwRAYIKwYBBQUHAgEWOGh0dHA6Ly93d3cucGtpLmFk
 bWluLmNoL2Nwcy9DUFNfMl8xNl83NTZfMV8xN18zXzIxXzEucGRmMEIGCCsGAQUF
 BwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJvb3QuY29tL2Jh
 bHRpbW9yZXJvb3QwDgYDVR0PAQH/BAQDAgEGMCcGA1UdJQQgMB4GCCsGAQUFBwMB
 BggrBgEFBQcDAgYIKwYBBQUHAwMwHwYDVR0jBBgwFoAU5Z1ZMIJHWMys+ghUNoZ7
 OrUETfAwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL2NkcDEucHVibGljLXRydXN0
 LmNvbS9DUkwvT21uaXJvb3QyMDI1LmNybDAdBgNVHQ4EFgQU/DVeWB34UuAr6Kyr
 uYKtFRHW5s0wDQYJKoZIhvcNAQELBQADggEBAJwbVrtGL68v2T0QhiuIKpFvNCpi
 2VpmyUwHY1IiIKxckiX9NoQdvSqwG9SePR3Fet9LC6d0SAnkXKTwnjP7hxTMdmMt
 +TK/UnJWBBQCfMjwFRs0oAEFwyxSr04R2ZWIV/8DlTSQ3hxH2LPlgJjVosQfvdSG
 nqYK0KY3c7vMRC7QbtAIrmxY4CTqtBHiPQy/CV6zdcCYxgsKl3iPxPQAHEMIG8DY
 CaMW+JsRUTtdPIaXIa559nmHbG2xw/tm7Ku4ieKsd9RNkDIbE5DEi/clf1Xn8bW4
 AiV4lLjW7oN6i5m4QrGeFtWIXZXBFiurMtplyoJ/wmNw70ArcqxbOc174n0=
 -END CERTIFICATE-

 On Thu, Feb 5, 2015 at 6:33 PM, s...@gmx.ch wrote:

 Hi all

 A few weeks ago, I got some mails about a broken iframe. The secure 
 connection to the remote server failed (OCSP error). The site was 
 signed by Swiss Government SSL CA 01. I contacted the technical 
 support and they told me, that the Federal Office of Information 
 Technology, Systems and Telecommunication (FOITT) of Switzerland shut 
 down their OCSP servers! So all secure Swiss gov sites are broken if you
 requires OCSP.
 I contacted them directly and tried to explain why the OCSP service 
 is a requirement for a CA, but they do not react.

 Maybe someone of the Mozilla security team could contact them again.

 Regards,
 Jonas
 --
 Rob Stradling
 Senior Research  Development Scientist
 COMODO - Creating Trust Online

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




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

FOITT does no longer support OCSP

[sjw]

Hi all

A few weeks ago, I got some mails about a broken iframe. The secure
connection to the remote server failed (OCSP error). The site was signed
by Swiss Government SSL CA 01. I contacted the technical support and
they told me, that the Federal Office of Information Technology, Systems
and Telecommunication (FOITT) of Switzerland shut down their OCSP
servers! So all secure Swiss gov sites are broken if you requires OCSP.
I contacted them directly and tried to explain why the OCSP service is a
requirement for a CA, but they do not react.

Maybe someone of the Mozilla security team could contact them again.

Regards,
Jonas



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Indicators for high-security features

[sjw]

Hi

I would support your idea, but it's quite hard to implement it. If a
server use TLS 1.2 and HSTS, you still don't know if the connection is
really secure.
But it would be easier if Firefox would show more details about
protocol, ciphers etc.


Am 17.09.2014 um 17:20 schrieb Richard Barnes:
 Hey all,

 Anne suggested an idea to me that I thought would be interesting for this 
 group.  Consider this email a rough sketch of an idea, not any sort of plan.

 There are a bunch of security features right now that I think we all agree 
 improve security over and above just using HTTPS:
 -- HTTP Strict Transport Security
 -- HTTP Public Key Pinning
 -- TLS 1.2+
 -- Certificate Transparency
 -- Use of ciphersuites with forward secrecy
 -- No mixed content
 -- Content Security Policy (?)
 -- Sub-resource integrity (?)

 It would be good if we could create incentives for sites to turn on these 
 features.  EFF has already seen some sites trying to turn things green on 
 their Encrypt the Web Report [1].  Should we consider creating a suite of 
 features that comprise a high-security web site, and create some UI to 
 express that to the user?

 We could invent new UI for this (e.g., a green lock icon), or we could 
 overlay these requirements on the EV criteria.  Chrome already does this to 
 some extent, downgrading the EV indicator to DV if the site attempts to POST 
 to an http://; URI or (soon) if the site doesn't do CT.

 What would people think about creating a list of security features that must 
 be enabled in order to get special UI (EV or otherwise)?  We would obviously 
 want to coordinate this with the other browser vendors, and to some degree 
 with site operators (though the whole point here is to lean on them to do 
 better!)

 Thoughts?  Suggestions?

 Thanks,
 --Richard

 [1] https://www.eff.org/encrypt-the-web-report
 ___
 dev-security-policy mailing list
 dev-security-policy@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-security-policy




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy