Tag Info

Hot answers tagged

118

It is already done: It is the FPKI root CA, under explicit and full control of the US government. Windows already trusts it by default. Before you flip out and begin to delete root CA certificates, burn your computer's motherboard, or drink a gallon of vodka, think about what it means. It means that the US government could technically emit a fake ...


83

My favorite current resource for cold, hard, real world data is the Verizon 2011 Data Breach Investigations Report. An excerpt from page 69 of the report: Actions The top three threat action categories were Hacking, Malware, and Social. The most common types of hacking actions used were the use of stolen login credentials, exploiting ...


60

You are absolutely correct in your assumptions. If you are using a computer owned and operated by your employer, they effectively have full control over your communications. Based on what you have provided, they have installed a root CA certificate that allows them to sign a certificate for Google themselves. This isn't that uncommon in the enterprise, ...


43

This recommendation makes no sense: The JavaScript code used to hash or encrypt the password has to be transferred to the client too. If the attacker is able to mount a man-in-the-middle attack he will be able to inspect the JavaScript code used for encryption too or might even replace it with something else (like no encryption). Hashing instead of ...


24

SSL protects data in transit by encrypting it. It only ensures, to a client, that data will make it from their computer to your server without being intercepted or altered (the encrypted data could be intercepted but has no meaning without decryption). That said, it is the client's responsibility to ensure that SSL is functioning properly before they send ...


22

Updated: For HTTP you can use Burp Suite's proxy (Java), or mitmproxy. tcpcatcher is a more general Java-based GUI capture and modify proxy which might be closer to your requirements, it includes content decoding and modification (manual and programmatic). It's HTTP biased, but accepts any TCP. It has SSL support, though the only drawback seems to be ...


22

The simple answer is no - there is a wide variety of evidence that this type of attack is common. Some of the controls brought in by banks (two factor authentication etc) were in part required to combat the ever more common MITM attacks on customers. While there are other forms of attack (compromise of client is a good one) which may now be easier to carry ...


21

Yes, that last someone is correct, in addition to encryption (confidentiality) HTTPS gives you the assurances that the form is coming from where you think it is (authentication), and that it has not been interfered with in transit (integrity). Without HTTPS the form could be modified by a MITM as described. It'sNot using HTTPS for this is simply bad ...


17

You can't. The best you can do is to use SSL sitewide. Have all HTTP connections immediately redirect the user over to HTTPS (redirect over to the front page via HTTPS, e.g., http://www.example.com/anything.html should redirect to https://www.example.com/). Don't serve any content over HTTP (other than an immediate redirect to your front page, over ...


17

The short answer is: No, not always. I have studied this topic in depth and please read this entire post before forming a conclusion. SSLSniff is a proof of concept exploitation platform to leverage flaws in the PKI, such as vulnerabilities in OCSP or the (ingenious) null-prefix certificate attack. If you are using a fully patched system, and you ...


16

1 and 2 are answered by David Houde 3: There's not actually any way to tell for sure whether you are securely talking to Gmail when using your company's machine (aside from auditing the machine down to the metal). Even if they didn't change the cert, they could simply modify the web browser to forward all decrypted traffic somewhere. There are a million ...


15

Your case is common in the corporate world, it is usually described as corporate MiTM. When you connect to the Internet from inside your network, you're likely connecting to a gateway/router the belongs to your company first. That router can simply hand you public key in a "fake" certificate whenever you connect to an SSL-enabled site and fool your browser ...


15

Here are my recommendations for what users can to defend themselves against SSLstrip, Firesheep, and similar attacks: Install HTTPS Everywhere or ForceTLS. (HTTPS Everywhere is easier to use.) This tells your browser to use the SSL versions of web sites, where possible. If the browser gives you a certificate warning, do not bypass the warning, and do not ...


14

ARP spoofing usually works by fooling all the clients into thinking that you're the router, by faking the ARP responses that translate IP addresses to MAC addresses. When clients receive the ARP response, they remember the MAC that was associated with the IP. Once you stop the application that's handling the man-in-the-middle part of the operation, the ...


14

The point of the server certificate is so that the client can make sure that it knows the correct, genuine public key for the server. Certificates signed by a CA are one way to achieve that (with the unspoken assumption that we trust the CA for signing only certificates with correct information in it, and not goofing it up). A self-signed certificate cannot ...


13

Yes, a VPN connection encrypts the connection between your computer and the remote VPN host. The connection would just look like gibberish to anyone sniffing the traffic, either in the coffee shop or on the Internet. It is worth noting that the same applies to any content sent over HTTPS even if you aren't using a VPN. It is also worth noting that if you ...


13

See what the servers answer: RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:b8:1d:61. and: ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:d8:0f:01. That's not the same key type, therefore not the same key: RSA in the first case, ECDSA in the second case. SSH servers can use several cryptographic algorithms, and ...


12

A router misbehaving and trying to act as a fake server with regards to the client, and a fake client with regards to the true server, forwarding data in both directions, is the exact definition of a man-in-the-middle attack. Apart from routers (which act at the IP level), classic practical methods for MitM include: hijacking a HTTP proxy subverting the ...


11

Products which purport to be able to filter SSL-encrypted traffic usually do so by doing a man-in-the-middle attack, just like an active attacker would do. The "security product" sits on the Web proxy, through which the connection is performed. It intercepts the flow, and generates on-the-fly a custom certificate with the name of the target site; the client ...


11

Full-fledged NTP implementations only allow a limited skew. For example, the de facto standard (formerly ISC) implementation on Linux will not deviate from the local clock by more than 1/2000 by default (a bit less than one minute per day). Hence an attacker cannot cause a huge clock deviation with such an implementation. In a typical site-wide or server ...


11

It is not the certificate which matters, but the private key. That one does not leave the server. To impersonate the server, the man in the middle would need to obtain that private key. The certificate itself is public data, and sent by the server to every client who asks for it by simply connecting. (A Man in the Middle attack is a double impersonation: ...


11

No, this is not possible. Depending on the key exchange mechanism in use, there are (slightly) different mechanisms for proving the identity of the server. This is defined in RFC4253 where it requires "explicit server authentication." In the case of RSA (RFC 4432), the server signs a piece of data provided by the client (actually a hash of several pieces) ...


10

The way that SSL and TLS work is that there is some way to provide authentication for at least one side. Normally the server has a private key where the client has the fitting public key (or, more usually, some root public key of a certificate chain which certifies the public key of the server). Alternatively, also some password-based authentication methods ...


10

Short answer: Yes and no. First of all, let's get things straight. How does key-based authentication work in SSH anyway? Once the SSH connection reaches the authentication phase, the client signs a bunch of data (this includes the session identifier) with its private key, then sends the signature to the server to verify it. Signature verification pass -> ...


10

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


10

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


10

No, it is not true. Being able to recover the key, while knowing the original message (the "plaintext") and the encrypted message (the "ciphertext") and the algorithm, is called a known plaintext attack. If the attacker not only knows the plaintext and the ciphertext, but actually gets to choose either, then this becomes a Chosen-Plaintext Attack or a ...


10

Microsoft's 3rd immutable law: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." So you have to trust the people running your data-centre. That's what trust means in information security: it's what you are reluctantly forced to do when you can't fully control, avoid, or transfer a risk. Still, you will want to ...


10

SSL only secures the connection between client and server. In theory it does it fairly well (ok, there are some problems - but these are minor compared to all the other problems :) as long as none of the about 150 CA you trust inside your browser gets compromised or works together with some agencies and gives them intermediate CA to do man-in-the-middle ...


10

You are correct. Some ways for the site to decrease that attack vector would be to... Use an HSTS header to prevent any data from being sent to the site in plaintext. Advertise only the HTTPS URL and do not allow any plaintext connections. This will ensure most bookmarks use encryption. The point being that sites should force SSL from the beginning, ...



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