Tag Info

Hot answers tagged

82

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


58

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


23

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

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


20

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


19

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


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

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


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

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


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

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


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

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


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


12

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


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

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

Not, it is not true... .. Unless the ISP is good at spying on people, and you are gullible. In that case, things are possible. Explanations: to "snoop" on your communications, the ISP must either break the SSL crypto (fat luck on that) or impersonate the server to power a Man-in-the-Middle attack. From the client's point of view (your Web browser), the ...


9

They are doing post submission over SSL. This will provide protection against a passive MITM since the credentials would be encrypted on the post back, however, it does effectively nothing against an active attacker that is able to alter traffic since they could simply alter the postback URL and the user experience would not change. A smart client could ...


9

The recent compromise of certificate authority DigiNotar resulted in the issuance of over 500 fake certificates for google.com, microsoft.com, cia.gov, and hundreds of other sites. These certificates somehow made their way into 40 different Iranian ISPs, resulting in a massive man-in-the-middle attack, confirmed to have affected over 300,000 Iranian users ...


9

They will get a CA that is in the CA root zone for all browsers to issue them valid certificates. This CA will probably be a UK based company. Spying will be completely transparent to the users. Browsers will show no warnings. This will work for a few days, until it is detected by the public at which point browser vendors will revoke the root certificate of ...


9

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


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



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