Tag Info

Hot answers tagged

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


59

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

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

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


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


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


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

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


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

Rather than "bypass" encryption, they can spoof the identity of the server, so as to perform a MITM attack (effectively). Encryption itself is only one part of the configuration when setting up an SSL/TLS connection: this ensures the confidentiality of the communication between the client and the server. Before that, the client needs to verify the identity ...


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



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