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

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


11

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


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


7

All or None. The singly-rooted CA trust paradigm we inherited from the 90s is almost entirely broken. Vanilla browsers do not track or alert if the Certificate Authority backing a SSL certificate of site has changed, if the old and new CA are both recognised by the browser1. As the average computer trusts over a hundred root certificates from several ...


7

There is no risk of compromising the private key, because you send only the CSR which contains the public, but not the private key. But using a CA is in effect a trust delegation, as people trust your certificate because they (or the browser) trust the CA that signed the certificate. Once they notice that the CA is no longer trustworthy (like DigiNotar after ...


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


6

To be intentionally recognized, the trusted certificate authorities (CAs) will need to get their root certificates pre-bundled with specific web browsers and operating systems (OS), like Microsoft Internet Explorer, Apple Safari, Mozilla Firefox, Google Chrome and Opera (et al.). The trusted root certificate list is usually updated periodically to add or ...


6

The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points: Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used ...


6

... But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question. This just is a very important part. If you don't verify, that the peer you ...


6

From RFC 5280 3.3 Revocation An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. If you have a lot of changes (people leaving etc.) it's best to not make the certificate validity too long otherwise the CRL can grow large (some CRLs are > 30MB which ...


5

There is no World Overlord because there are too many candidates for the post. The whole X.509 protocol is completely up to the task of having a single root CA. However, there is no single root CA because people could not agree about who should thus be entrusted with complete power over all certificates. Or, from another point of view, there is a Global ...


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


5

The risk of using a shifty-looking CA is not in the certificate enrollment process: as long as you generate the key pair yourself and send only the certificate request to the CA (which contains only the public key) and receive the raw certificate in return (not a PKCS#12/PFX archive), then your private key is yours and yours only. The risk, though, is in ...


5

You are correct that SSL uses a asymmetric key pair. One public and one private key is generated which also known as public key infrastructure (PKI). The public key is what is distributed to the world, and is used to encrypt the data. Only the private key can actually decrypt the data though. Example time. Say we both go to walmart.com and buy stuff. ...


5

There is no global directory of all issued certificates (X.509 was designed to support the Directory, but it never existed in practice). You will have to contact "all CA" and ask them nicely. Basically, this would mean going to their site, and using the "I lost my password" feature so as to regain control of your account, if it exists. Details vary depending ...


4

PKI-based signature and encryption works this way (in email and any other application): When signing data, you need access to the private key When validating signed data, you need access to the public key When encrypting data, you need the public key When decrypting data, you need access to the private key. Now, a (X509) certificate is a set of data that ...


4

Installing a "trusted root" on a victim's computer requires local administrative rights. If the attacker can do that, then he has already won. Hacking into the CA's server to obtain a fake certificate is a way for the attacker to be able to masquerade as various "trusted" servers and issuers (e.g. to make fake "signed" OS updates), in order to breach into ...


4

Personally I completely disagree with any form of security assertion on a webpage. I'm writing a blog at the moment about exactly this. Many financial institutions features things like "Log In Securely Here" links and pictures of padlocks dotted all around the place. A simple SSLstrip attack and the user is browsing the page over http:// yet they are ...


4

To view your certificate stores, run certmgr.msc as described there. The "root" store contains the root CA, i.e. the CA which are trusted a priori. certmgr.msc shows you an aggregate view of all root CA which apply to the current user; internally, there are several relevant stores (the "local machine" stores apply to all users, the "current user" stores are ...


4

This is not encryption that you need. Well, you might need it too, but that won't do the whole job. Encryption is for confidentiality: you encrypt the token if you don't want the client to learn the token contents, i.e. his permissions. Maybe you indeed want to hide that information from the client, but that's a secondary concern. The primary security ...


4

This is most likely an obsolete "bridge" now leading to the wrong place. There are two valid trust chains for this cert. There is a root cert for GeoTrust Global CA, valid from 2002, which is in current Windows/IE and Firefox stores (and Java); and also a "cross-signed" cert for that CA under Equifax Global CA as follows: Data: Version: 3 (0x2) ...


4

As far as X.509 is concerned, there is absolutely no problem in having several certificates with the same public key. The validation process is described in full details here; in a nutshell, it is verified that: each certificate in the chain is currently valid (with regards to its start and end dates for validity); the signature on each certificate is ...


4

There is a standard for STARTTLS in plain HTTP. Note that "STARTTLS" is still SSL; it merely modifies the dynamics, but no implementation complexity is avoided that way. Generally speaking, nobody uses STARTTLS for HTTP, mostly because it is less secure. Indeed, a very big part of SSL-for-Web-browsers is the visual feedback, by which the user is made aware ...


4

Yes, it is possible, but the better question is would they? The CA's reputation is their life blood. Why would they give a trusted signing authority to another CA that might not hold up to their standards (and could be a direct competitor in the future.) To the best of my knowledge, no CA offers this kind of service, nor do I see any reason why they would ...


4

Not only could they - some do. But they are effectively delegating their monopoly to you they will charge you a LOT of money for the privilege (as in if-you-need-to-ask-then-you-cant-afford-it). Its not cost-effective unless you are issuing a HUGE number of certificates.



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