Tag Info

New answers tagged

8

[...] is there any way that they can communicate without Eve reading the messages? Nope. Against an active Man in the Middle attack (active adversary traditionally named "Mallory") like this one, you're out of luck. Against a purely passive MITM (passive eavesdropper, traditionally named "Eve") this would have worked.


10

The presented case is the prime example why a self-signed certificate provides almost no security at all: it can encrypt the data but is impossible to authenticate it. Anyone can create any certificate in name of anything and have it encrypt data. That's why there is the certification chains in HTTPS and key signing on PGP keys, for example. In this case, ...


1

As long as the data travels inside a properly configured SSL/TLS connections, there is no security issue regarding the increase amount of data sent through the internet, the only downside would be an increased load on your server. If you cannot trust local storage, then fetching the data from the server when it is required seems the best option from a ...


2

The problem with what your asking for is that there isn't a 1 to 1 mapping of the OSI layer to actual implementations. The OSI layers are really conceptual more than physical. In reality, the demarcation between the various layers is very blurred, which makes it near impossible to implement a tool which can break things up and break them into specifric layer ...


0

It depends on what type of MitM attack you're working with. ARP Poisoning - This only works when you have an Ethernet connection on the LAN, since it works by spoofing identities using OSI Layer 2 technologies, ARP MAC-to-IP bindings. This seems to be the type of attack you are familiar with. BGP Redirection - This works on the Internet since it involves ...


0

There is a walkthrough of the entire process here -- http://sign0f4.blogspot.com/2014/10/mitmf-v07-released-sslstrip-integration.html In summary, the author of the blog posts demonstrates using sslstrip2 and dns2proxy to capture credentials. While the author is using his own MITMf tool, the tool encapsulates sslstrip2 and dns2proxy, as well as the hsts ...


0

(B, C, D, R), which ones can attack if the target is A? B and R. Both B and R can spoof the IP address of E and can see the SYN-ACK reply packet from A to get the sequence number for the final ACK. C cannot because the ACK will be sent via R that will route the packet out onto the internet. D cannot because it will not see the SYN-ACKs over the ...


2

Your protocol is not safe by any means! Example for MitM: A sends random nonce G1 to B C intercepts and sends nonce G1c to B B sends back hash_k(G1c) and random nonce G2 C intercepts and sends hash_k(G1) and nonce G2c to A A verifies hash_k(G1) (is OK), then sends back hash_k(G1 | G2c) C intercepts and sends back hash_k(G1c | G2) B verifies and a ...


1

No. Stick to known protocols such as TLS, Kerberos, SSH & IPSec for key exchanges. Try researching Diffie-Hellman key exchanges and ECDH (Elliptical Curve Diffie-Hellman, the new method of key exchanges like your example).


0

For you custom app, you can bundle the public keys into the app, and keep the private key on your custom device. You're already distributing an application, so including the key with it is no big deal.


4

A Man-in-the-Middle really is simultaneous double impersonation: the attackers poses as a fake server when talking to the client, and as a fake client when talking to the server. The beauty of the MitM is that since the impersonation is simultaneous, the attacker can hope to reuse answers from the genuine client or server, when responding to the genuine ...


0

Any CA can emit (and use) a valid certificate for any domain. It doesn't mean it won't be detectable, as the certificate won't be identical to the genuine one, as they would need the private key (presumably securely held by the site being impersonated). Certificate pinning will detect it (either built-in the browser, as some do for select sites, or with an ...


1

There are some news articles about existing backdoors on CAs for use by Security Agencies, but the trustworthiness of these news must be checked, New NSA Leak Shows MITM Attacks Against Major Internet Services There is no evidence that shows the trusted CAs use their certificates for MITM attacks, because sooner or later will be identified or disclosed ...


1

It may depend on how your certificate is installed. If your client doesn't recognize your certificate, then there's your problem. Go read up on how certificates work to understand what's happening here. If your certificate is installed as a globally-trusted root CA, then the browser will assume that a public CA is behaving badly again, and won't let the ...


2

These sites set the HSTS header (HTTP Strict Transport Security). If you have visited these site without the Burp proxy before, your browser knows (cached) the HSTS policy and sees a mismatch. The HSTS Policy specifies a period of time during which the user shall access the server in a secure-only fashion. HTTP Strict Transport Security (HSTS) is a web ...


5

About Chrome According to https://www.google.com/chrome/browser/privacy/whitepaper.html In the event that Chrome detects SSL connection timeouts, certificate errors, or other network issues that might be caused by a captive portal (a hotel's WiFi network, for instance), Chrome will make a cookieless request to http://www.gstatic.com/generate_204 ...


2

The most common reason for this is that you are connected to an enterprise network that has active proxying, data loss prevention, filtering or similar. In order to do that for the increasing number of encrypted sessions, "clever" security devices perform a man-in-the-middle attack on your connection by replacing the normal certificate with their own. So now ...


-2

You could also look into NFC only communication to transmit. That way you can corral the user into an area and have a good look. This would prevent the MITM part. Trunk out the lines into multiple stations and you can have drop points for the data.


1

Won't WPA+802.1X solve this? AFAIK, this means that no client can sniff the others' packets. I'd recommend that you double-check this before moving forward, but that's what I've understood from some brief re-reading (I haven't used 802.1X in years).



Top 50 recent answers are included