Tag Info

Hot answers tagged

111

Whilst I don't know the specifics of your ISP, I would say that it's likely that what they're doing here is intercepting all traffic you send over the Internet. In order to do that (without you getting error messages whenever you visit an HTTPS encrypted site), they would need to install a root certificate, which is what you mention in your post. They need ...


55

Unless the Superfish malware has been installed on your system, (which it might if you bought a Lenovo machine,) you don't have to worry. This attack worked because the secret it revealed was necessary for the malware to hijack the data; it is not a part of how legitimate certificates are authenticated. It helps to understand the relationships between a ...


42

This is a request to surrender all your privacy and security to them. It is a very simple technical issue - they have blocked encrypted and secure HTTPS connections. "Reenabling" it by installing their certificate will now allow you to use encrypted and "secure" connections, but it will give your ISP full access to view your online data, modify anything ...


34

What makes Superfish, and similar products (all herein just referred to as "Superfish"), different from corporate MitM is that Superfish is doing the MitM on the client machine. Corporate MitM is performed on a separate server or appliance. This is important because the system performing the MitM must have the private key of a Trusted Root CA in order to ...


28

Mostly yes, any CA in your trusted root, (or subordinates) can issue a cert for any DNS name. Name constraints and Enhanced Key Usage can be used to mitigate this, but they aren't enforced everywhere. DANE, Certificate Pinning, and Certificate transparency are a few projects that help protect from this risk.


28

Because of how Superfish works, the certificate and its private key must be easily extractable. Superfish creates signed certificates on the fly for the network connections it intercepts, without contacting a central server. In order to do this, the private key for the Superfish CA must be embedded in the software in an easy-to-use form. Now, they didn't ...


17

Can any CA sign any cert for any domain? In general, yes. Trusted root certs are trusted for anything under the root. If the answer is yes, what prevents having two different CAs creating a valid cert for the same domain? Nothing - it's completely legitimate for you, the owner of example.com, to go get a certificate for www.example.com issued by ...


15

It's prevented through legal (contractual) and not technical means. What happens if a CA creates an certificate which is not duly authorized by the legitimate domain owner: Time passes, with users unknowingly trusting the fraud. Somebody notices and reports it. Browser vendors remove that CA's root certificate from the next update to the trusted list All ...


11

In effect your ISP is reading all your mail. Think of your internet connection as a series of letters being sent over pony express. The error you are seeing is your browser complaining that your mail has been opened by someone and resealed with the wrong wax seal rather than the expected, for example Google's, wax seal. What your ISP is telling you to do ...


7

I agree this sounds very dodgy, but I might have an idea that might help, I can only assume you are using your ISP DNS servers, and I assume you are using a router. Why not just change the IP address to your external DNS server to something like Googles open DNS servers 8.8.8.8 and 8.8.4.4. If that stops the error message and assuming you have NOT installed ...


6

Hopefully, someone will do the testing and give a definitive answer for Kaspersky for you. Meanwhile, here's an answer for the general case: It depends. Does running an SSL proxy against yourself weaken your security posture? Certainly. Will any given product weaken your security posture as bad as Superfish? That's very implementation-dependent, and also ...


5

Others have mentioned mitigation techniques, here are some examples: Questionable Compromises Antivirus manufacturers like Kaspersky frequently install a CA in order to "protect" you by eavesdropping on all your connections, including SSL links. In February 2015, media covered the SuperFish adware / malware deliberately installed by Lenovo on its ...


5

Within SSL/TLS, the server sends its certificate chain systematically to the client (well, unless the client wants to negotiate a cipher suite that uses no certificate at all, but that's pretty rare in practice). See the TLS standard, in particular this diagram, which says it all: Client Server ClientHello ...


4

No, you can't trust it. It is possible that: The real site has suffered a compromise of its private key One of the many certificate authorities whose root certificates are in your browser has suffered a compromise of its signing key One of the certificate authorities is not following procedures correctly and is issuing certificates that it shouldn't be ...


4

You at least need : documents to describe processes involved in certificates life cycles : *request for a new certificate *certificate revocation *certificate renewal both for administrators and users (probably two different documents for each process) a general architecture document, describing CA levels and their purpose That's in my opinion ...


4

Certificate Authorities cross-sign each other when they get married together. When CA Y issues a certificate for CA Z, then any system who trusts Y will indirectly gain confidence in everything that Z issues, since, for any certificate X issued (signed) by Z, a system that trusts Y will build the chain Y→Z→X. Thus, this cross-certification represents an ...


4

The main difference between Superfish and a Corporate Proxy is how the new SSL certificate is generated. In the Superfish case, the CA certificate and the private key stands on the client computer, and the software generates a new SSL certificate with a key it have on itself. The traffic is intercepted locally, a new certificate is generated on the client, ...


3

Some companies are very concerned about information leaking onto social media sites. Because of this, they will put in proxies that inspect the content of data sent to social media. When they do this, they issue their own certificate, and it behaves in the way that you describe. Is it normal? Not for the average user, but increasingly normal in corporate ...


3

You claim: digital signatures are used to verify the trustworthiness of information. This is right, at least for some interpretations of "trustworhtiness". Actually, a digital signature can be used to verify that the information has been created by some entity having access to the private key to the public key referenced by that signature, and has not ...


3

To sign something digitally, it is necessary for me to have a private key and for the matching public key to be transmitted to the message recipient over a secure channel that prevents tampering or substitution. I can then easily prove that I originated the message by hashing the message, encrypting the hash using the private key, and attaching the encrypted ...


3

I have done some research on the Lebanese Internet Regulation Act. Basically, your minister of information, Walid Al-Daouq, proposed a law in 2012 (which didn't make it) that would have put heavy stress on the freedom of speech in Lebanon. The law has since been stopped, but it's possible that your ISP has come under pressure from the government to monitor ...


3

There is actually very little in the TLS specification itself about certificate verification. The TLS specification is sufficiently flexible to allow for types of authentication other than X.509 certificates, such as OpenPGP certificates or Kerberos. There are some expectations and references to X.509-related concepts, such as the certificate_authorities ...


3

The CSR is checked for validity. If it is valid, then the old signature is stripped out and a new certificate is built. The ingredients for the new certificate are as follows: Info from CSR (Plus some fields added/changed/removed. Whatever your CA feels is best.) Typically some basic constraints (Such as the statement: "What I'm signing here is (or is ...


3

As long as the machine in question has enough entropy to generate strongly random keys and nonces, that's totally correct. The key must never leave that server. Even more, if I were working on a critical application, I wouldn't even trust that machine and keep the key in a HSM. It might cost a lost, but it significantly enhances the security. There is a ...


2

It depends on what fingerprint you mean. The public key fingerprint is a hash of the public key only. Since the public key stays the same on a simple renewing, this fingerprint will be the same too. The certificate fingerprint as shown in the browser is instead a hash of the complete certificate. Since the contents of the certificate will change to ...


2

A server can use a self-signed certificate to identify itself. Clients then have to trust this certificate when they connect or use the server's service. In PKI infrastructure you normally don't have the CA generate the key-pair unless its the root certificate. Clients and intermediate CAs will generate their own key-pair and use the CSR to have the ...


2

Since Windows Vista and Windows 7, Windows has an automatic procedure of downloading new root certificates. So for example if you connect to https://www.hongkongpost.gov.hk/index.html and Windows does not (yet) have the root certificate, the root will be downloaded from Microsoft if Microsoft thinks the root can be trusted. So to answer your question, it's ...


2

In this case, cert 1 is known as the root certificate. You download it and install it from the university's website. The server certificate is cert 2, which is what the university's website presents to your browser at every visit. cert 1 is used to sign cert 2. When you connect to the university server through SSL, you will be presented with cert 2 and your ...


2

Certificates establish authentication (tying a person to an identity), which is the wrong approach to limit access to b.example.com - a user is still themselves on both sites, and all authentication's concerned with is having them prove their identity. Limiting access is authorization, which you should do on your end by actually checking the ID contained in ...


2

If you follow best practices when it comes to protecting private keys of root certificates it most certainly would not have been that easy. If I understand Robert's blog correctly the password that protected the private key was embedded as a string in the adware binaries that shipped with the laptops. This is like shipping your safe together with your key ...



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