--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
I wanted to know if the CAs in question would be found only by actually making the change, given the phrasing "Any reports of interstitials ... put the CA on notice." But it sounds like you those CAs already have been put in notice, so that's good.On the risk, I'd like to understand what the .002% number means in terms of proportion of pages views affected, or a qualified guess if there is none. Can one just multiply by the proportion of page views that use HTTPS at all, or is it more complicated?
certificate errors we use interstitials which have a click-through
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
RFC 2818 states: (Section 3.1, para 4)
"If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead."
By removing support for the CN field, surely Chrome becomes RFC non-compliant (regardless of deprecation) because the RFC states that "Common Name field in the Subject field of the certificate MUST be used" if the CN is not present? How can the MUST be obeyed if the certificate contains only a populated CN field and no populated subjectAltName field if the use of CN is deprecated in Chrome?
In any case, from the perspective of private PKIs, this may be challenging from an operational perspective. For example, the default "WebServer" template in Microsoft ADCS does not use subjectAltName. Whilst this default template can be copied and modified to include the subjectAltName field, reissuance of all these already issued Web Server certificates may be a significant undertaking for those organisations with private PKIs using Chrome if this policy is implemented.
--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.
We use our MS CA for other non AD integrated applications, and we actually have the subjectAltName field disabled for any certificates that are only authenticating one domain, user, device, etc. and only have the Common Name field to verify against.
There may be others in this situation as Microsoft actually recommends disabling the SubectAltName field, see this link https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx
God...there are days I really believe some browser programmers are so far away from their users and breaks or complicate HTTPS/SSL/TLS stuff in the name "of security" to the worse by for example breaking or hindering SSL scanning / MITM in most ways possible as by enforcing HSTS in the browsers or this unnecessary change to ignore the CN field in favor of SAN even if CN never was declared dead AFAIK.
It turns out that CentOS 6 and CentOS 7 ship with OpenSSL configured to generate certificates with only CN, no SAN.
Mozilla's reference guide to server side TLS configuration talks a lot about algorithms, but doesn't even mention subjectAltName:
https://wiki.mozilla.org/Security/Server_Side_TLS
The official OpenSSL site seems to have nothing relevant in the documentation:
https://www.google.com/search?sitesearch=www.openssl.org&q=subjectAltName
Microsoft presents it as an extension which can *damage* security and "increase the risk of impersonation attack":
https://technet.microsoft.com/en-us/library/ff625722%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
Given the above and the fact that I'd never seen a single set of instructions for SSL even mention SAN before all our certificates stopped working, I'm betting there are a lot of angry people out there.
Next time, please:
- Evaluate how many people are likely to be affected
- Make prominent public announcements, not on a developer mailing list
- Provide instructions for fixing the problem
- Deprecate, rather than proceeding straight to the "throw up an error page" approach
It should have been handled more like the SHA1 or TLS 1.0 deprecation transitions.
God...there are days I really believe some browser programmers are so far away from their users and breaks or complicate HTTPS/SSL/TLS stuff in the name "of security" to the worse by for example breaking or hindering SSL scanning / MITM in most ways possible as by enforcing HSTS in the browsers
or this unnecessary change to ignore the CN field in favor of SAN even if CN never was declared dead AFAIK.
Same with SSL warnings in a browser in general. Long time ago I liked chrome for it´s simple, logic and intuitive Cert warning approach "red warning page for a certificate issue" with a direct accessible "Proceed" Button shown instead a oversized warning page which has to be expanded everytime to continue to a warned website. This definately is not a security improvement, this is only enforcing people to follow many sequential steps to reach a website instead simply go to a "proceed" button on a red warning page.
--
So are you going to patch OpenSSL to make it easier to generate CSRs with SANs then because this is insane and requres zsh? Ask any random sysadmin how to generate SAN CSRs and they'll be googling for an hour.
openssl req -new -newkey rsa:4096 -nodes -sha256 -out ${domain}.csr -keyout ${domain}.key -subj "/C=US/ST=MyState/L=MyCity/O=${company}/CN=${domain}/emailAddress=ab...@example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${domain},DNS:www.${domain}"))
--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.
Hi,
I tried to googl for those criteria, but didn't find them, can you
On Thu, 27 Apr 2017 07:16:32 -0700 (PDT)
feld...@gmail.com wrote:
> I have recently been informed this breaks Common Criteria FIA_X509
> SFRs which requires that CN matching works on certificates without
> SAN. This would make Chrome no longer compliant for the federal
> government. More investigation will be needed as I am still looking
> for the specific language that defines this requirement.
point to a source? Or are they nonpublic?
Is there any justification for that requirement? Or is it more an
example of gov certifications doing pointless things without a reason?
Ok, so this policy demands that verification has to happen, period. It
would not be in compliance to use software that doesn't actually
verify the name on the certificate matches. This is good.
> Verification using the Common Name is required for the purposes of backwards compatibility.
I interpret this as requiring that Common Name has to work, but they
prefer SAN. Chrome isn't removing the ability to match names via
CommonName which would create a vulnerability, but are denying
validation of certificates that use CommonName (unless extra setting
for local trust anchors). Is this still within compliance if they are
explicitly requiring the backwards compatibility? I wonder what an
auditor would say because I can see it both ways.