Slashdot Mirror

Google is a net newbie, and although they think and act (incorrectly) like they know what they're doing, they want to be a (bad) nanny to everyone. What ever happened to "don't be evil?"

You say this as if Google de-trusting this CA in October is a Google choice.

FireFox limited trust for this CA back in May already, and will be revoking it in October as well.

May 2018 (Firefox 60): Websites will show an untrusted connection error if they have a TLS cert issued before 2016-06-01 that chains up to a Symantec root.
October 2018 (Firefox 63): Removal/distrust of Symantec roots, with caveats described below.

Only Microsoft hasn't announced intent to do so for IE/Edge, in violation of the certificate authority standards I might add.

There are clear rules CAs must follow and they are not ignorant of this.
Symantec knew full well they would have all of their CA certs revoked from all web browsers the second they sold wildcard certificates for traffic interception systems.

This is no ones doing other than Symantec.

What are the negative impacts of encryption?

I think the right question to ask is "what are the tradeoffs of moving to encryption?". The hardest part about designing a system for the web is that the costs are borne by everyone, while the protection offered needs to fit the most vulnerable person. There is no way for a browser to force the server to behave in a certain way, while the deployment of HTTPS almost exclusively benefits the browsers, not the servers.

To me, the situation is very clear cut, the benefits of universal deployment of HTTPS vastly outweigh the costs. I can understand and respect other people looking at the situation and coming to a different conclusion, but I want to make sure that the facts on the table are correct first.

My experience tells me that the most obvious approach to changing the cost equation, namely negotiating how much security is required in each a given context, will not work. The main limit is that people only defend against attacks they can imagine, and their five seconds of imagination is not as thorough as a billion dollar intelligence agency. Tapping all US backbones to snoop all internet packets and save them for future reference seemed wild until it was a well-established truth.

(Also, having more negotiation simply means more options which are less tested and more likely to be broken in ways we haven't noticed. Like IPSEC tunnels with a billion options that are easy to accidentally run insecurely even with a full team of experts vs. OpenVPN.)

I'll answer your examples point by point.

2) Increased bandwidth requirements as caching servers are rendered moot

This is the one argument against HTTPS by default that resonates with me. Bandwidth problems are real, and caching is important. Unfortunately caches are inherently in conflict with the confidentiality part of security. The cache has to see the response to store it and the cache has to see the request to check the cache. I think the current state of the art is that you can proxy your connection through the cache, if you choose to trust it. This only rules out transparent caches. Designs where either the server or the client has a cache it can trust are workable.

Maybe some day we can use fully homomorphic encryption databases to create caches that don't break the confidentiality guarantees, but that's strictly research material today.

3) Automatic ability to identify you uniquely when using a service

I'm not sure what you're thinking of here? What unique identifier does TLS have that HTTP doesn't? I would expect that encrypting more data means that there's less to use to fingerprint a client?

4) Requires CA (Let's Encrypt helps, but modern HTTPS really does not promise who is on the other end anymore)
6) Most of the "attacks" described could just as easily happen via malware, which is still an issue. This removes only one attack vector and even then incompletely (leading to false sense of security, see 4).

Ah, I see. It's a waste of effort to work on curing cancer because people can still die of AIDS. Even in the field of computer security, we can separate problems and solve them independently, even when there are other vectors that cause the same symptom.

If you think that CAs don't promise who's on the other end, I encourage you to demonstrate by standing up a server that responds with a valid cert for gmail.com. CAs are far from perfect, but they're also far from HTTP. There's policy enforced through audits (and even auditors can be distrusted, third point), and more recently there's technical enforcement too. If you make a gmail.com cert you either don't upload it to the CT log

Yes, there are actual standards: https://cabforum.org/documents...

There is a solution to this: have two grades of certificates, ....

There is already that kind of arrangement. Lets Encrypt issues DV (Domain Validated) certificates, and quite short lived because validation is fully automated and contiains potential risk being abused.

The other two commonly used server/client certficate types are OV (Organisation Validated) and EV (Extended Validation) which requires much more careful vetting of the applicant before issuing the cert.

You can find information about certificates, set baselines, requirements of vetting etc. coordination effort from CA/Browser Forum.

More than ever we would need a method of restricting who and which CA's are able to issue certificates for which TLD's. We are still in situation where whoever CA can issue certificates for whatever domain names they like and that's really what would need to be fixed ASAP.

ps. IMHO - Trusting Lets Encrypt certificates is just a tiny improvement of situation all of us turning off browser warnings about self signed certificates. It doesn't make things much worse or better . But if security matters you should uninstall or remove Let's Encrypt CA from your client and accept that you at least get warning that the issued certificate is not trusted. You really don't know who is the other party and you should not trust by default but make justification case by case accepting each server certificate each time and consider not saving certificate unless it's your own service which you manage yourselves.

The idiots behind let's encrypt don't understand that the first and role of the public CA system is identity non-repudiation, but they issue certificates with any name to anyone who asks.

You don't have a damned clue how this stuff works, do you?

All the public CAs issue non-EV certificates based on the ability to control email and/or DNS information for domains, and most of them automate it. Their verification standards for non-EV certificates are on page 13 of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.7.pdf.

Let's Encrypt does exactly the same verification and meets those standards. Let's Encrypt is actually ahead of some of them in that it uses a published and publicly reviewed verification protocol (ACME) to check control over the DNS.

Yes, the CA infrastructure is shit, mostly because all you have to do to impersonate any domain is to find any CA you can trick. No, Let's Encrypt is not any worse than the hundreds of other CAs that the browsers trust.

from the actual request:

"Our CRM system suffered a data loss, and it looks like it rolled back to an old backup. As a result, we lost audit data for about 147 roots."

see: https://cabforum.org/pipermail...

Currently a lot of certs are broken in Edge and IE.

I didn't see that mentioned in the mailing list, is that just something Softpedia (the author) assumed? If so, I guess it's not that bad ("just" archived audit logs gone missing from their CRM).

To be approved for inclusion in pretty much any reputable application, a CA has to conform to the requirements laid out by the CA/Browser forum; see https://cabforum.org/wp-conten... -- you'll note that Section 9.6.3, bullet 5 requires the ability for the domain holder to request revocation. Let's Encrypt conforms to these requirements. While ACME requires specific authentication material to perform automatic revocation, there's a manual process in place.

From https://letsencrypt.org/reposi... : "To report private key compromise, certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to certificates, please email cert-prob-reports@letsencrypt.org."

Basically, all LE's policy says is "We're not going to make a unilateral decision about whether the content someone is hosting on their own domain is legitimate, for that way lies madness. If a domain owner needs a cert revoked, and they can't use the automated tools to revoke it, they need to send an email, and we'll take care of it as soon as we can verify that they're the rightful owner of the domain."

I'm not sure it gets much more reasonable than that.

• 2015-11-01 Issuance of Certificates with Reserved IP Address or Internal Name prohibited.
• 2016-10-01 All Certificates with Reserved IP Address or Internal Name must be revoked.

And:

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name.

Nothing is stated about November 1st 2014?

This is mostly FUD.

Regarding external certificates, most certification agencies (at least those that are members of the https://www.cabforum.org/ have stopped issuing certificates for invalid domain names for any date posterior to November 1st 2015. They put this policy in place on Nov 1st 2012. Any such certificates that might be marked as valid beyond that date will be revoked on October 1st 2016.

Now, there may be a concern with internal certificates for such domains, but that is for the internal policy of businesses to fix in time. It should be easy to implement redirecting policies to new domains for any internal web site or system that could collide with gTLDs before they're actually implemented. It is certainly NOT a serious security concern in my opinion.

Because they are forbidden to issue a certificate with a greater validity than 39 months in accordance with the CA/Browser Forum Baseline Requirements for Publicly Trusted Certificates (warning: PDF). If they were to violate this, they'd have GTE's root certificate de-listed by Apple, Google, Mozilla, KDE, Opera, Blackberry and ... um ... Microsoft. Which would invalidate their subordinate certificate.

if an HTTPS site uses a certificate that's domain validated, Dragon raises a warning "that the organization operating it may not have undergone trusted third-party validation that it is a legitimate business."

I'm all in favor of checking whether a commercial site has an identifiable, legitimate business behind it. We do that with SiteTruth, and it filters out a huge number of junk sites. We divide SSL certs into three categories - "domain control only validated", "business validated", and "extended validation". A "domain control only" cert has no identify value. The CA/Browser Forum is formalizing this distinction with their new cert issuance guidelines. The 3 levels of certs are now an industry wide standard.

SSL certs aren't the only game in town. There are other hard data sources for validating web sites. We use SSL certs, BBB and BBBonline records, purchased commercial databases of businesses, US Securities and Exchange Commission filings, and a few other sources. If a site is selling something and comes up empty in all of those, maybe you should buy from someone else.

I'm not saying that such sites should be blocked by a browser, though. Moved down in search results, yes. Users warned, yes. Hard blocked, no. (However, links to them in emails, tweets, and forum posts are a good indication of spam.)

Comodo has something of a conflict of interest in checking for certs, but they do accept certs other than their own. It's not a paid "Seal of Approval" racket.

This is a step forward. Not a huge step, but a step. There's a standard, and although it's weak, it's at least there. And, importantly, there's a list of who's signed onto complying with it. The CA Browser Forum says that 94% of the issued certificates were issued by their members, and there's a list of all 40 members. All root certs from non-Forum members should be removed from browsers. Some browsers now recognize as many as 200 CAs. A purge is in order.

There's now a way to check whether a CA claims to comply with these rules. If the cert contains OID 2.23.140.1.2.2, the identity of the business behind the cert has supposedly been validated. If the cert contains OID 2.23.140.1.2.1, only the domain behind the cert has been validated. If it doesn't contain either of those, after July 2012, it's worthless. Browsers should be adjusted accordingly. Note that, for the first time, there's an actual verification process for business identity for non-EV certs. This is a big step forward.

I'm very interested in the validation process for business name information, as described in section 11.2.1 of the specification. We use that info in SiteTruth, and we'll be tightening up our cert validation, now that there are standards.

It's not clear how this will interact with Akamai's practice of issuing secondary certs for their customers, so that Akamai's caching servers can present SSL certs from companies Akamai represents. Akamai isn't a CA itself, and isn't a member of the CA/Browser forum.

Currently, root certificates are wildcards, usable for any TLD. They need to be restricted to a single TLD, or a short list.

Single-nation CAs and government-operated CAs should be restricted to their TLD. For the generic TLDs, ("com", ".net", etc,) the CA/Browser Forum should require the CAs to post a large bond, from which a penalty is forfeited if any improperly issued cert is found. That should get the problem under control.

I think the proposal you are referring to (Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates) is not about EV certs but a proposed less-stringent standard for non-EV certs.

You may be right. But it's hard to tell. The CA/Browser Forum was originally limited to discussing policy for extended validation certificates. General certificate policy was managed by the IETF through the usual RFC process. Now, the CA/Browser Forum may be making statements about general certificate policy.

I think the proposal you are referring to (Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates) is not about EV certs but a proposed less-stringent standard for non-EV certs. Here's the announcement and request for public comment.

I think the proposal you are referring to (Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates) is not about EV certs but a proposed less-stringent standard for non-EV certs. Here's the announcement and request for public comment.

The CA/Browser forum (which is dominated by certificate authorities) is proposing to make changes in the way EV certificates are issued. The changes weaken EV certs.

Existing EV cert policy is that EV certs MUST contain the organization name, its business name and address, and its jurisdiction of incorporation. In the proposed draft, (p. 13) "Organization name is OPTIONAL".

This essentially makes EV certificates meaningless. The whole point of an EV certificate is to unambiguously identify the business owning the certificate. So if you need to sue, file criminal charges, or send in a collection agency, you know where to send the process server, cops, or collection agents.

(At SiteTruth, our system considers SSL certificates without a business name and address to have no value in establishing the legitimacy of a company. We've always done this for "domain controlled only" certs, and will now do it for EV certs missing a business name or address.)

The CA/Browser forum (which is dominated by certificate authorities) is proposing to make changes in the way EV certificates are issued. The changes weaken EV certs.

Existing EV cert policy is that EV certs MUST contain the organization name, its business name and address, and its jurisdiction of incorporation. In the proposed draft, (p. 13) "Organization name is OPTIONAL".

This essentially makes EV certificates meaningless. The whole point of an EV certificate is to unambiguously identify the business owning the certificate. So if you need to sue, file criminal charges, or send in a collection agency, you know where to send the process server, cops, or collection agents.

(At SiteTruth, our system considers SSL certificates without a business name and address to have no value in establishing the legitimacy of a company. We've always done this for "domain controlled only" certs, and will now do it for EV certs missing a business name or address.)

Hi I am Yuvaraj, Being in Comodo Marketing Intelligence Team, I can assure you that the Best to go for would be Comodo SSL certificates. I can give the Justification of why you need to choose Comodo. 1.) Speed & Stringent Verification Process - For True Assurance 2.) Cheap at Price and High at Quality & assurance 3.) Gives You a Corner of Trust Logo for free* to make the visitors trust you 4.) Unique, patent-pending EV AUTO-Enhancer(TM) - Automatic EV Deployment and Maintenance Technology - automatically upgrades Microsoft® Internet Explorer 7.0 on Windows(TM) XP to full "Green Address Bar" functionality. Valued at $1,500, Comodo provides this technology free to all our EV SSL Certificate 5.) Industry Leading Support - you can visit http://www.instantssl.com/ and can see how our live support team functions. 6.)Comodo is the initiator of the CA/B forum (Certification Authority / Browsers Forum) visit http://www.cabforum.org/ And also you can get a free trial certificate......and then if you are satisfied ( I know for sure you will get satisfied) you can go for the paid ones. Thanks, Yuvaraj

Domain: www.entrust.com

Server identity:
CN = www.entrust.com
serialNumber = DOC:19961216
OU = it
O = Entrust Inc
jurisdictionOfIncorporationStateOrProvinceName = MD
jurisdictionOfIncorporationCountryName = US
L = Ottawa
ST = Ontario
C = CA
Issuer identity:
CN = Entrust Certification Authority - L1A
OU = (c) 2006 Entrust, Inc.
OU = www.entrust.net/CPS is incorporated by reference
OU = CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY
OU = AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE
O = Entrust, Inc.
C = US Certificate has 10 extensions.

• Extension #0: keyUsage = Digital Signature, Key Encipherment
• Extension #1: privateKeyUsagePeriod = Not Before: Jan 12 13:57:28 2007 GMT, Not After: Jan 12 14:17:41 2009 GMT
• Extension #2: extendedKeyUsage = TLS Web Server Authentication, TLS Web Client Authentication
• Extension #3: authorityInfoAccess = OCSP - URI:http://ocsp.entrust.net
• Extension #4: crlDistributionPoints = URI:http://crl.entrust.net/level1a.crl
• Extension #5: certificatePolicies = Policy: 2.16.840.1.114028.10.1.2 CPS: http://www.entrust.net/cps User Notice: Explicit Text: The Entrust SSL Web Server Certification Practice Statement (CPS) available at www.entrust.net/cps is hereby inc orporated into your use or reliance on this Certificate. This CPS contains limitations on warranties and liabilities. Copyright (c) 2002 Entrust Limited
• Extension #6: authorityKeyIdentifier = keyid:7E:B7:FC:4C:26:E6:B0:7A:FB:54:E2:3C:45:73:C6 :43:90:5E:28:04
• Extension #7: subjectKeyIdentifier = 10:E0:70:1B:D7:78:17:32:B4:BA:EB:00:6A:E2:25:C3:67 :FC:77:1D
• Extension #8: basicConstraints = CA:FALSE
• Extension #9: UNDEF = None (this is a bug in the cert. viewer)

The CA Browser Forum has published a standard for these certificate. So that's what we go by.

How do you tell this is an Extended Validation certificate? That's not in the CA Browser Forum's standard. It's dependent on the certificate issuer.

It's documented, on Entrust's web site "Each EV SSL Certificate issued by the Entrust EV SSL CA to a Subscriber contains an Object Identifier (OID) defined by the Entrust EV SSL CA in the certificate's certificatePolicies extension ... which by pre-agreement with Application Software Vendors, marks the certificate as being an EV SSL Certificate.

The following OID has been registered by the Entrust EV SSL CA for inclusion in EV SSL Certificates: 2.16.840.1.114028.10.1.2"

That OID number appears in the middle of a comment in the certificatePolicies extension. So, for each issuer, you have to look for something different.

The certificate checker has to be really careful. To verify that a certificate is an Extended Validation certificate, it's not enough to find that OID. You have to make sure that the certificate was issued by the issuer entitled to use that OID. Otherwise, it's easy to forge these certificates.

But if you're too thorough in the checking, the certificate bounces. The whole point of an Extended Validation certificate is to validate the company's identity. So we have the new fields "serialNumber", "jurisdictionOfIncorporationStateOrProvinceName", and "jurisdictionOfIncorporationCo

I love Slashdot I really do. Nowhere else do you get such a combination of highly-opinionated yet spectacularly ignorant people. Except perhaps Fox News. Let's get some facts on the table here.

1. This is not a Microsoft initiative
2. This is about the Extended Validation Certificate programme which involves a large number of organisations, most of whom are CAs.
3. The EVC is the initiative of the CA/Browser Forumhttp://www.cabforum.org/
4. The point of EVC is to raise the game of the CAs in terms of actually checking who has bought an SSL certificate from them, which is what should have been the case when SSL was invented but which market forces ensured did not happen.
5. This is not just about IE7. Firefox, Opera and other browsers will also process EVCs and many may use the green bar. IE7 is likely to be the first browser to use them, but it will not be the last.

A teeny tiny bit of research by any half-normal human would have revealed the above. But nooooo, this is /. where a$$hole opinions are the only condition of entry.

As a case in point I just loved killjoe's "contribution", where he admitted hacking someone else's PC to get a crappy unsigned app running on it. If some moron did that to my PC he would get a screwdriver in the eyes.