Tag Info

New answers tagged

0

root or Administrator access is usually required to modify the CA bundles. If an attacker has gained that level of access, it's game over. Defending against such a scenario is almost impossible as there are many other things the attacker can do. Now, for the very specific case of SuperFish, browsers (and other applications) can push updates to reject that ...


0

You can read out the certificate's "Common Name" field and then pass it to the back end like so: http-request set-header X-SSL-Client-CN %{+Q}[ssl_c_s_dn(cn)] And if you then combine this with the a CA of your own issuing the certificates, then you can put a username in that field. And then read it out with HAProxy. Described here: ...


0

while the other amswers are correct about implementation details, the security issue in play is one of authorization. In the case of Superfish and related stuffs, the system owner typically doesn't want Superfish to be able to read all the stuff that is sent and received via HTTPS. On your home computer, you probably don't want Superfish to have your ...


0

There is not much difference between a valid and expired certificate in the SSL/TLS communication. Both case will allow the communication in a safer way and also the same level of data transmission. Even the certificate is expired , the keys are valid until its compromised. Here the point is that the level of trust to the client. But as a Standard SSL ...


1

Actually the Base CRL will have the next update time for each issuance. So the client who is verifying the CRL will first validate the signature and then the next update CRL time. In your case, if the client is using the old CRL , it will miss the new CRL entries. but for this scenario, the client needs to verify the server who issuing the base CRL regularly ...


2

Base and delta CRL are linked together through the CRL Number. The "CRL number" is a monotonically increasing integer that, roughly speaking, characterizes the age of the information contained in the CRL. From the point of view of the validator (the "client"), a delta CRL can never be used alone, but only in combination with a base CRL, subject to the ...


1

you can run following command in a command prompt (with administrative rights): certutil -setreg chain\minRSAPubKeyBitLength 512 this will set back the required key length (less secure!) see https://morgansimonsen.wordpress.com/2013/05/30/what-does-the-this-certificate-has-an-invalid-digital-signature-message-actually-mean/ for more information. quote ...


37

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 ...


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, ...


2

PKI-administrator is not really a well defined role, so the scope of his documentation is vague here. As a Chief Information Security Officer I would ensure that the following documents exist: System Administration doc, for a technical audience - sysadmin who need to set up servers and clients (configuration, architecture, ...). Some interesting point ...


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 ...


1

If you don't intend to perform client authentication via SASL or the like, a certificate is needed only for the server. Just embed the public key you generated in the app and use it for certificate pinning. If get your certificate signed by a CA in Android trust store, you can use Android TLS utilities without any extra step, since the verification will be ...


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 ...


1

The answer as to why you cant simply take the signed public key and use it to intercept traffic in a man-in-the-middle style attack is that you (or the attacker) wont have the corresponding private key that goes with the public key. So the browser will receive the web servers or the CAs signed public key, and will use that to encrypt its own secret to send ...


1

If you want to authenticate a client to your server, you will need a private key for each client. The usual HTTPS method (TLS) uses only one certificate to authenticate a server. The server has his public key published and signed by some authority, the client verifies the certificate and the authority signature of the certificate, then the client is sure ...


7

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 ...


1

As AJ Henderson suggested, the perfect solution would be to have the OpenPGP card sign the CSR. It turned out that is possible with the gpgsm CLI tool. Damien Goutte-Gattat from the GnuPG-user mailing list answered the question: Is there any way to create an X509 CSR signed with the private key stored on the card? Yes, you can use the ...


2

Superfish acts as a Man In The Middle. It dynamically generates keys which your browser trusts for domains you visit. To generate those keys it needs the private certificate, and while more obfuscation is possible, in the end it can't conceal that key. What could be done though is to generate a unique key pair for the Certificate pair on each computer ...


1

Most of the certificates are updated through whichever update mechanism that is available to the system. You cannot be certain that the certs that are installed with the browser are not effectively used for mitm. On the other hand, you could write a small script that uses openssl client mode to retrieve the x509 certs of SSL based targets and from there do a ...


0

There is no such thing as a safe or unsafe certificate. In that sense all certificates as equal. Certificates are only about trust. When can you trust a certificate? You could do a thorough investigation to who is behind (who holds the corresponding private key) each of the 36 certificates and do an audit of their policies yourself. Most people however ...


1

What you're asking to do is possible but quite difficult. First of all you need to understand a few ideas so here we go. Firstly, signature schemes. You've no doubt looked at digital signature schemes on the web and you might rightly ask - so why don't you just sign the whole file? Well, the answer to that is that in at least the case of RSA, you open ...


56

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 ...


30

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 ...


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 ...


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 ...


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 ...


1

The summary answers you wanted: The Issuer field is a DN which identifies who signed the certificate. A DN (Distinguished Name) is one of those wacky "C=US, O=HAL, OU=Discovery One, CN=Dave Bowman" strings But having the right name only counts if you're in the local trusted roots! But to your main question - nothing needs to change about the ...


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 ...


0

All browsers inherently trust DigiCert True enough. (and I assume it's intermediate CA?) Clients may include trusted intermediate certs, but cannot be expected to. It is your job, the server, to provide any intermediate certificates necessary to validate your certificate chain up to the root (RFC 5246 7.4.2): certificate_list This is a ...


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 ...


0

I found a good explanation here: https://technet.microsoft.com/en-us/library/dn786436.aspx To summarize it: In case of 1 layer design (RootCA issues endpoint certificates) - it´s not recommended due to obvious reasons. In case of large and expensive 3-layer design, you get great scalability, you can enforce different CA policies on each of the off-line ...


0

From my experience, CAs do have their own settings and they are often not willing (or are not able at all, because it is wired into their software) to change anything in it. I´m talking about mandatory Subject fields, key usage, extended key usage, ... For example you would like to have L, ST, C in the Subject, but CA will cut is off and you get hte ...


1

For proxying, it is possible to use Burp for android: https://systemoverlord.com/blog/2014/07/13/passing-android-traffic-through-burp/ (this second set of instruction assumes you are using an emulator) http://resources.infosecinstitute.com/android-application-penetration-testing-setting-certificate-installation-goatdroid-installation/


0

No actual security system works like you describe, for exactly this reason. The certificate is not used to encrypt the shared secret to verify that they have the same secret; that would be pointless (you might as well just have one side generate the secret and send it encrypted with the other side's public key). When the shared secret is generated using data ...


0

You can go with any of the tunneling mechanism to accept the particular IP's in the server side or else simply configure your firewall to accept the list of trusted clients.


0

the Java keystore contains certificate information To be more precise it contains public keys or key pairs (public and private key). The keystore is protected by a password and every private key is also protected by a password. However you are able to change or remove passwords. It's up to you. A Java keystore is like a detached keystore of a web browser ...


1

Alice sends hello to Bob which contains a code A. Eve intercepts the message and instead puts a code E. The above just won't happen. before Alice sends anything, Alice requests the CA to verify bob.com(Eve), the response from CA won't match Eve, so Alice will receive a warning saying that Bob's certificate is invalid. If somehow Alice has Eve's ...


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 ...


0

This type of problem lends itself to Cargo-Cult Security type "solutions". In the real world there is no possible mechanism that can prevent a rogue client from connecting to your service. A VPN is a proven security system that allows trusted clients access to a trusted network, but the internet is inherently untrustworthy. The attacker will have access ...


0

A self signed cert will effectively work as a SSH public key. You will have to add each users certificate to your list of trusted CA's. If a user does not have a cert already, you can create it using java script in the browser during sign up. You can ask the user to store their private key certs encrypted with strong passwords so it is not exactly the same ...


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 ...


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 ...


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 ...


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 ...


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.


0

You are not the first to think of this. See the last sentence in PKIX rfc5280 3.3 X.509 defines one method of certificate revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time-stamped list ... A new CRL is issued on a regular periodic basis ...


0

Yes You are right, the password is protecting the private key. First question here is that already the key got revoked , why do you want to use it the revoked one again. Is there is a intentional reason to work on it ? You can open the public part by using the keytool command.The command follows here keytool -list -keystore -storetype pkcs12 -rfc It ...


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 ...


1

To answer number 3: It is in my list of trusted root certificates (windows 8.1) Windows uses these settings you are looking at, and some browser have their own list, others depend on the windows list of trusted roots. Chrome seems to use the OS: http://www.chromium.org/Home/chromium-security/root-ca-policy Firefox has it's own list: ...



Top 50 recent answers are included