Tag Info

Hot answers tagged

31

A CA is supposed to make sure that the certificates it issues contain only truthful information. How they do that is their business; serious CA are supposed to publish detailed "Certification Practice Statements" that document their procedures. In practice, when you want to buy a certificate for a www.myshop.com domain, the CA "challenges" you, so that you ...


12

Certificate Authorities make a living based on their reputation of only giving out certs to the rightful admins of a domain. If a CA starts giving out too many fraudulent certs, the browsers will pull out their root cert and the CA goes bankrupt, so it's in the CA's best interest not to do this. Exactly how a CA verifies the identity of the applicant varies ...


11

"Remaining anonymous" and "verifying identity" are contradictory, aren't they? I would say if you want to pay someone and guarantee that they get the money, they can't remain anonymous. If I ask them to give me a personal password and in return I give them each a unique public key, will that be enough to verify their identity assuming they took ...


5

They can not read your traffic, because the communication between you and the entry node is already encrypted.


5

If the MITM attack was done using arp poisoning (for example in public WiFi network), then you will not see the attackers IP anywhere. Lets say the default gateway of a WiFi network is 192.168.1.1. The attacker can send arp responses to your machine telling it that he is 192.168.1.1. Your machine will continue to send packets to the address 192.168.1.1, ...


5

Such compromises already happened and DigiNotar is just on example. In effect the attacker could impersonate almost all certificates this way, because for most certificates it does not matter who signed it but only that it was signed by a CA trusted by the browser. There are few exceptions which are thus safer: Chrome and Firefox (and IE with EMET?) have ...


5

how can they ensure that you are really an admin of this myshop.com, perhaps it was an attacker who requested this certificate to be able to perform man in the middle attack? They can't. If you can receive mail for admin@example.com then you can get a cert for that site. what prevents the same attacker from requesting the certificate for the same ...


4

Since all of the other subquestions have been adequately answered, I will attempt to answer the question regarding registration of domains that are similar to the original. This action is known as typosquatting and since the typosquatter owns the domain, they will have complete control over the verification requests that the SSL certificate authority ...


4

Email is insecure. It is completely insecure. Between you and the recipient it likely passed through dozens of servers and for each one it was passed as pure plain text. Without specific details and logs it is impossible to say where a copy was lifted but regardless you should always ASSUME that anyone can read anything you put in an email. If that ...


3

A provider of domain-validated certificates will typically ask you to create a TXT DNS record of their choosing for myshop.com or put online a web page of their choosing on http://myshop.com/, to prove that you own the domain. That will generally stop an attacker from getting an SSL certificate for your domain, unless they have already compromised your DNS ...


3

The compromise of a Root CA does not mean that all certificates signed by that trusted root are indeed compromised. Rather, it means that fraudulent certificates can be made for man-in-the-middle attacks and signed so they appear trusted in a browser. When you submit your Certificate Signing Request (CSR) to a Certification Authority (CA), they are ...


3

While your question looks complex I think it boils down to the following setup: two servers, client does not know which one is the correct one both require authentication with client certificates And your question is, if client authenticates against server A: can this server use the successful client authentication to authenticate against server B? The ...


2

You can't authenticate as the server The problem is not that the server will "throw a fuss" it won't. You can easily spoof the server into thinking you are the user. The user isn't authenticating with an SSL cert. The problem is you can't trick the user or more specifically the user's browser. Remember for a MITM attack the attacker needs to establish ...


2

DPI threats against OpenVPN is pretty hard, unless the attacker somehow grabs the random, freshly generated session keys which is transmitted over an SSL connection. The SSL connection, in turn, is secured using a pre-shared certificate and a secret server certificate. So an attacker would need to compromise the server itself. Usually, said attackers would ...


2

You can prove that someone owns an email address quite easily. You send them an email containing a random code, and ask the user to enter the code to confirm their email address. This is a very common technique for online signups, and the secret code is usually hidden inside a link, which the user has to click to confirm. As you have identified, there are ...


1

SN: 09:48:B1:A9:3B:25:1D:0D:B1:05:10:59:E2:C2:68:0A SHA-256 Fingerprint: EA:16:D6:DA:76:9B:67:6B:C0:7A:19:A0:CD:21:AA:F1:5A:9A:66:93:A2:C3:CD:7A:87:81:7D:B1:6F:5F:48:F5 Nothing in the cert I am looking at has opendns in it. IIRC OpenDNS does not support DNSSEC, they support DNScrypt-proxy which would not involve any cert being exposed to the browser.


1

To answer the original question - most people never type https://something.com directly. They rely either on links (click here to access our secure login server) or on redirects (type "gmail.com" in the browser, and you will be automatically redirected to a secure site). This is where SSLStrip comes in - it intercepts the original, unsecured HTTP reply, and ...



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