Tag Info

Hot answers tagged

24

Last year, I made a bet with a friend that I can get a browser-trusted certificate with his domain name in order to launch a successful MiTM attack on his login form to steal his password. Long story short: I lost the bet; I wasn't able to convince any of the 16 CAs I contacted that I'm the legitimate owner of the domain. Even though I had an email account ...


11

There is a handy script distributed alongside openssl, CA.sh to do most of this stuff. Its location is distribution specific. In Debian and derivatives you can locate it using: # apt-file search CA.sh openssl: /usr/lib/ssl/misc/CA.sh And RedHat and derivatives the (approximate) equivalent is: # yum provides */CA 1:openssl-1.0.1e-4.fc18.x86_64 : Utilities ...


11

The distinction depends on some details about the self-signed certificate and how the browser and the OS will react to it. A normal certificate includes a Basic Constraints extension which contains a flag telling whether the certificate is for a CA or not; when the flag is TRUE then the certificate is considered acceptable as an issuer for other ...


10

This looks like a poorly encoded name which was even more poorly decoded and reencoded. Initially, the name seems to be: A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH The name was then encoded in big-endian UTF-16. In this case, this means that every character yielded two bytes, the first of which having value 0. Upon decoding, whatever ...


9

Yes, a nation-state adversary can get a valid certificate for any site from any CA which they have power over. Whether it's legal or not is probably another question which I'm not qualified to answer. Keep in mind that, even if a hijacked CA starts signing certificates with CNs of popular websites like google.com in order to MITM their traffic, it will be a ...


9

and decrypted their SSL traffic by compromising a backbone router No, that's wrong (but it doesn't impact the rest of the question). According to that claim, the NSA compromised a router that belonged to the target (not that it really matters). More importantly, compromising the router did not help the NSA decrypt the SSL traffic: all it did was allow ...


9

Depending on how the CA does things, it may or may not have a copy of your private key. Usually it doesn't. The normal method is that you generate your private/public key pair on your own machine, then send the public key to the CA as part of a certificate request. The CA assembles and signs the certificate, and sends it back to you. Your private key never ...


8

Different CAs have different methods, and each CA has different methods based on what level of trust you are paying to have. (such as Extended Validation to get the green address bar) The little fly-by-night CAs have a base level verification where you just give them an e-mail address and they send you an e-mail there, thereby validating that you really own ...


8

There is a subtle point here. In the envisioned situation, there is one (or several) rogue CA who may emit fake certificates for man-in-the-middle attacks. The vulnerability here is not about a server who uses a (genuine) certificate from that rogue CA; it is about the client potentially accepting a certificate from that CA. To protect yourself (as a client) ...


7

According to your comments to other answers, you actually want to sign a pdf file with [your] certificate, then have this signature saved and appended to the pdf [you]'ve just signed. (BTW, you sign with the private key associated with the public key in your certificate, not with the certificate itself, but that's a detail.) I assume you want to ...


7

Strictly speaking, the server can send an arbitrary number of certificates to the client, as part of its Certificate message. However, as the standard says: The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Therefore, a really compliant server cannot send a ...


6

It's not standard for a commericial CA to insist on making your private keys. For reasons you mention. Here's a link pointing to a collection of CA providers that suggests (and rightfully so) that the typical thing is for your browser to create the key pair and then send the Certificate signing request to the CA. In my experience with high end Verisign ...


6

The documentation does not talk about it, but a look at the OpenSSL source code, in the apps/ca.c file, seems to indicate that the -updatedb command-line option will trigger a pruning of the index.txt database, converting expired certificates to "expired" status, which replaces the previous "revoked" or "not revoked" status. (OpenSSL is not the best ...


6

Generally speaking, you are the one who should decide who you trust and who you do not trust. However, this is a tiresome process; in its infinite wisdom, Microsoft (or Mozilla or Google or...) found it fit to include a set of "default trusted roots" that are used by Internet Explorer (or Firefox or Chrome or...). In the case of Microsoft, the process by ...


6

The problem with self-signed certificates is that anyone can create them for any name they want. When you issue a self-signed certificate for yourself, the identity of that certificate can read whatever you want. You could create a certificate which reads "Qmal", or one which reads "Google Inc." or "Western Union". That means it provides no security ...


5

A couple fundamental things: The basis of a CRL is a promise for a certain time period. That means a begin time and an end time. Once a CRL is made and signed, it can't be changed, so it lasts as long as it lasts, and can't be trusted after that. In essence, you won't know until you check. A CRL in its regular form is one big list. You can't assume ...


5

Trusted CA certificates are validated by a third party, called Certificate Authority. In a cryptographic sense, CAs are a trusted third party (TTP) validation authority in a public-key infrastructure (PKI): The primary role of the CA is to digitally sign and publish the public key bound to a given user. This is done using the CA's own private key, so ...


5

The EFF's SSL Observatory has generated a map of all Certificate Authorities. This map is so massive, there is a very high likelihood that one of these is compromised at any given time. The principle of the weakest link makes me quite wary of our PKI. Furthermore, it is trivial for a nation-state to afford that cost of becoming a delegate authority. A good ...


5

Browser plugins like Certificate Patrol for Firefox can warn you of changes since the last or first time you visited; but you'll find that a lot of legitimate network topology and load-balancing solutions have relied on this interchangeable trust flaw of SSL - so you'll end up with a ton of prompts and warnings while navigating the internet. You are correct ...


5

There is nothing technologically hard in issuing certificates. It is just a bit of encoding, and a signature; a basic PC can do that a thousand times per second. While CA don't normally indulge in on-demand certificate issuing, there is no inescapable technical barrier to it. The most plausible explanation is that you are currently connecting through a ...


5

You are assuming that trojan deployment is always possible. Assume that it is not, but that there are other methods at disposal to execute a man in the middle attack. For example a hacker has access to the victim router and can redirect DNS traffic to his own computer. Or a hacker gained access to a specific ISP DNS server and can then also spoof responses ...


5

As Rook said, the statement "Bob requests Alice' public signature verification key from CA. CA returns Alice' key..." is incorrect. Public Key Infrastructure does not require a CA to serve as a public key server. What would actually happen is that Bob would ask Alice for her public key. Alice would send her public key directly to Bob, signed by the CA. Bob ...


5

Short answer: because RFC 3280, its predecessor, says so. Longer answer: because historically ASN.1 encoders/decoders have had problems with properly encoding and decoding integers. X.509 uses DER encoded ASN.1, which amongst other things, means that the data must be encoded in its minimal (shortest) form. As integers are stored in a variable length ...


4

With such a certificate, any system who trusts your internal CA will trust a server running on "localhost" as being genuine, i.e. running really on "localhost". But "localhost" can be reached, network wise, only locally, so if your client successfully connects to https://localhost/whatever then it already knows that it is talking with the local machine. ...


4

I agree with AJ that even cheap CAs involve verifying emails from data retrieved from a WHOIS request. But this sort of verification often has many holes in it and doesn't cryptographically ensure the validation. That is an attacker who can eavesdrop/alter unencrypted traffic on the internet can potentially: intercept the email sent over the internet ...


4

First let's note that each of your servers will nominally have two keys and corresponding certificates. One is for use as a server in the SSL sense (when the browser, or another server, connects to the machine), and the other is for use as a client (when the machine itself connects to another server). You can arrange for both keys (and certificate) to be the ...


4

The first problem I can see is how do you find the first certificate? If you've visited the site before, then I suppose you could, but for anyone that doesn't keep certificates around from all the sites they have visited, we'd need some infrastructure to be able to look up all certificates that resolve for a particular CN. Additionally, such a system might ...


4

In order to be accepted as an issuer for other certificates, a CA certificate must be marked as such: they must contain a Basic Constraints extension with the cA flag set to TRUE. If a client (e.g. a Web browser) sees a purported server certificate chain, with the "X.com" certificate, not marked as a CA, used as an intermediate CA, then the client will ...


4

Nominally, in pure "X.509" philosophy, the SSL client should obtain the server's certificate and all needed intermediate CA certificates in any way it sees fit, but in particular by talking to the Directory, which is the giant worldwide LDAP server which contains everything. Unfortunately, the Directory never existed (too centralized, too complex) so ...


4

If somebody (anybody) has root/admin access to your machine, it's not your machine any more: you're, at best, sharing it with them. Technically speaking, they are free to replace any (or all) your root certificates with exact copies that just have a different public key. The only way for you to detect the forgery is to verify the fingerprint of EACH root ...



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