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


13

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


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


10

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


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


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


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


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

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

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

Though a CA does not need the private key to issue a certificate, certificates for S/MIME will be used for encryption: once you have an S/MIME certificate, people will send encrypted emails to you, and the emails will remain encrypted in your mailbox. This implies that losing your private key (e.g. your compute hard disk fails, or your laptop is stolen) ...


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

Once upon a time, you could check your root certificates against a paper book: http://www.cl.cam.ac.uk/research/security/Trust-Register/ These days, try to check as many independent sources as possible - for example install different browsers on different operating systems on virtual machines, and see if they agree with each other. If you are worried ...


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


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

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

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

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


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

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

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, e.g. people trust your certificate because they (or the browser) trusts the CA which signed the certificate. Once they notice, that the CA is no longer trustworthy (like DigiNotar ...


4

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



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