Hot answers tagged

22

The answer by user2320464 is good, but I'd like to expand more. Summary: The certificate holder generally does not manage their own revocation information, because the whole point of revocation is to announce that holder of this certificate is not trustworthy. The rightful owner of the cert needs to be able to declare the cert Revoked, but in a way that ...


15

Browsers do not accept verification from just any third party; if they did the whole exercise would indeed be pointless. In order to be accepted as valid, the certificate presented by the website must be digitally signed by a trusted certificate authority. The default list of trusted certificate authorities, which you can see in Chrome by going to Settings-&...


9

You better ignore that commenter entirely. Joey Spinosa is either royally confused or is trolling. There are many totally inaccurate statements in his comments; mainly from conflating Server Certificate with Certificate Authority Certificate. Claim 1: downloading files ... install these certificates of authority. Browsers never silently install a ...


8

The issue is caused by the unavoidable phenomenon of "Hash Collision" The dangers of trusting certificates that use SHA1 starts from the technique used by Certificate Authorities (CA) to sign them and how the web browser verifies them. As you may know the entire certificate is not signed, instead only the hash of the certificate gets signed. Lets assume ...


7

So is it a 256bit SSL cert? No. There are several aspects which are relevant for a certificate: the type of the key, usually RSA or ECC the size of the key. The strength of the key depends both on the type and the size, i.e. the commonly used 2048 bit RSA and 256 bit ECC keys are roughly equivalent the signature algorithm, i.e. SHA-256 + RSA When ...


6

The real security risk of using SHA-1 (or MD5) certificates is indirect, and therefore easy to miss. The problem isn't the security of the server's real certificate, it's the client policy that allows the client to trust low-security certificates. Consider two scenarios here (and I'll use MD5, because it's already been proven inadequate): A client connects ...


6

This is an awesome idea - to manually trace through the cert validation process! I've enjoyed reading through your steps, since I've never actually done it myself! Answering your questions: First question: Is this the correct way of obtaining the certificate the *.wikipedia.org certificate was signed with? After all, how can I be sure ẁikipedia.org didn'...


5

A TLS cipher consists of a part defining the authentication of the certificate (i.e. ECDSA, RSA...), a part defining the key exchange (ECDHE, DHE...) and a part about the kind of symmetric encryption and the associated HMAC, i.e. RC4+SHA1, AES128+SHA256 etc. From these parts only the authentication part depends on the type of certificate and everything ...


5

First off, let's be careful about language, when you talk about a public CA like Entrust, or Verisign, or Digicert, yes there is some software involved for actually creating and managing the certificates, but you're really talking about the people. These companies are trusted CAs not because of the software they use, but because their network admins take ...


5

Typically certificates are revoked by the person being issued the certificate. So if you were to purchase an SSL certificate and later found the private key was compromised, then you would revoke the certificate. This action would be recorded on the "Issuing CA" where the serial number of the newly revoked certificate would appear in the Certificate ...


4

The behaviour of HSTS is variable depending on whether the includeSubdomains directive is applied. In the case of HSTS without includeSubDomains, a user visiting www.facebook.com wouldn't protect them if they accidentally went to ww.facebook.com without an explicit HTTPS prefix. However, when the includeSubDomains directive is applied, visiting any subdomain ...


4

I sneakily edit a sneaky MITM attacker into your image: The problem with this protocol is that Bob does not authenticate with Alice. That means a man-in-the-middle attacker who can manipulate the data-flow between Alice and Bob can intercept the initial connection attempt from Alice and respond with their own certificate. Alice will then communicate ...


4

CloudFlare's Origin CA is working as intended. It's not trusted by browsers. It's only trusted by CloudFlare's servers. Its purpose is to secure communications between CloudFlare and your origin, not for general usage. Reference: Introducing CloudFlare Origin CA If you want a free, publicly trusted certificate, check out Let's Encrypt. (It's a legitimate ...


4

The way certificates work is that a certificate is sent by the web site to your computer. Your browser reads the certificate, looking for the identity of the "signing certificate." It then validates the signature of the downloaded certificate was created by the signing certificate. If the signing certificate is signed by itself, it is called a trusted ...


3

TLDR: in limited cases yes, but don't First, key-exchange and authentication aren't really independent in SSL/TLS. Although there are sometimes a few choices available, many combinations you could reasonably choose do not exist as ciphersuites. (Unlike for example SSH, where the pieces are negotiated separately and you can get any combination as long as ...


3

Update in response to your edits in the question You are correct that validating a cert up to the trusted root is not 100% foolproof. What it guarantees that a trusted CA issued this cert to the domain that you are communicating with (because you can check that the URL in the cert matches the URL that you are establishing the SSL connection with). This was ...


3

Snapchat used to use a famously weak crypto implementation with a global key stored in the source code to encrypt pictures at rest, so they are infamous when it comes to security. But, luckily enough, all communication is over HTTPS. That means the owner of the network (your company) can not MitM the users (your friend) and read the content of their ...


3

So is it a 256bit SSL cert? No. Yes. Maybe. The real answer is: It depends on the terminology, as some CAs appear to be notoriously lousy about such details. The certificate contains the public portion of the asymmetric key pair that is used to authenticate the server (ensure that you really are talking to the server you think you are talking to) and ...


3

My guess is that your proxy administrator has turned off ssl-inspection for google domains because of an update of Chrome, and what ciphersuites it will attempt to use for google domains. https://forums.bluecoat.com/forum/security-policy-enforcement-center/proxysg/37493-proxysg-is-offering-unknown-elliptic-curves-chrome-google-connect-failure Unfortunately,...


3

"Anything may be crackable given enough time and resources." Here is a good article that explains the differences of key size. Now imagine you exaggerate and create a 8192 key can it be cracked? Likely not. Are you safe? This all depends on the security of the system. If someone can compromise your machine and steal the key you made, the encryption ...


3

Is EV green extended validation slower than a regular SSL? A EV certificates is just a normal certificate but with a few special issuer specific X509 extensions. The browser compares these extensions against the extensions expected for EV certificates on the issuers CA and if they match it will show the green EV bar. These special X509 extension are not ...


2

I believe you're asking the wrong question. The right question is "Should someone new to security be working on a root CA?" and the answer is "probably not." It is highly likely that what you're doing will expose everyone who relies on your root CA to high risk of compromise. This has been demostrated by mature companies like Dell (see, for example, http:/...


2

As an addendum to dr jimbob's answer: There are utilities that look for these patterns and try to extract keys that way. Disclaimer: I have not tried any of these utilities. This post is just a nicer version of the links posted by user "void-star" on HN. (See below.) Whitepapers about the general idea: Adi Shamir and Nicko van Someren, 1998-09-22, ...


2

In case of cacert.org, they are presenting a self-signed certificate and that's why your browser complains. There is no trust chain that leads from the certificate to a root CA that you trust. If you were using a Linux distribution that comes with their certificate pre-installed, you wouldn't see a warning. It would be inferred that by using such a system ...


2

You are correct on your first statement. Unless s/he is a trusted CA, your browser will still bitch that the cert is not trusted. And you'll know you're being MiTM'd. For the second paragraph, you're reaching a bit.The hacker would have to compromise DNS for ALL CAs and have a way to validate the bogus certs. Highly unlikely.


2

If I understand your scenario correctly: You're talking about a security mechanism that relies on signatures made by 1024-bit RSA keys. You have a relatively easy way of deploying updated certificates and revoking the old ones. It's a matter of days, maybe months, but certainly not years. The public record for breaking RSA is a 768-bit key. Nation-states ...


2

It is the responsibility of the person who bought the certificates to ensure the security of the cert. It is the responsibility of the CA to revoke any certificates that were sighted breaching the terms of service. A certificate is a lot like a driver's license. If someone steals it, you have to report it.


2

Since there is no way to cryptographically invalidate a certificate, a system must be used to publicly announce the revocation of a certificate. The Online Certificate Status Protocol (OCSP) is the current way of doing this. Browsers can check an OCSP provider to confirm that a certificate is not revoked before connecting to a website.


1

From the Wireshark trace on B2, we see that the client is simply not responding at all; after one minute, the server grows impatient and closes the connection. This is probably not a problem of certificate availability on B2: if SChannel simply believed that it had no appropriate certificate, then it would send back an empty Certificate handshake message. ...


1

Your question about when / how to renew the CA key is a good one, but I'm afraid that it doesn't have a generic answer; it depends on which applications are consuming those certificates and how they expect a CA to behave as it approaches its end-of-life. One thing that is universally true is that end-entity certs should never outlive any CA in their issuing ...



Only top voted, non community-wiki answers of a minimum length are eligible