Hot answers tagged

64

The sniffing problem is about "confidentiality", which whitelisting does not cover, as the traffic can be intercepted and read. The MitM problem is about "authenticity", which whitelisting does not cover either, as an intercepted packet can be modified without evidence of tampering. I assume the whitelisting uses IP addresses, which can be arbitrarily ...


36

There are many, many ways you can become a MITM, virtually at all layers of the networking stack - not only the physical one. Being physically close to your target can help, but is by no means a necessity. At the physical layer, the attacks you can get are very overt: splice a ethernet cable, use a optical tap, or capture radio signals. A passive ...


34

TL;DR: Get the traffic routed through a system under your control and have MITM whereever you, the victim or the destination are. A: Not quite. First off, the internet is packet switched, so there might not be a single actual wire all packets go through. To establish a MITM, that MITM must make sure the requests from the user get routed to him instead of ...


13

If the data is unencrypted, anyone sniffing the packets between your server and their server can see it. A whitelist only lets their server verify that the source of the data. It doesn't assure that no one sniffed it during transfer, or that it wasn't intercepted and manipulated at any point during the process. In short, encrypt the data, keep the whitelist ...


10

The adversary doesn't necessarily need to be physically located on the network route that they're hacking. They may have previously compromised a network device that is on the route, and thus be able to login to it and conduct their attack from any location.


7

Assume, you have a girlfriend, and you saved her number as GF in your phone. And in the same way, your girlfriend saved your number as BF in her phone. Now an attacker X, manages to gain access to your phone, and change your GF number as his number. In the same way, he manages to gain access into her phone and changes your number as his number. So the ...


5

Those sites (and some more) use public key pinning with HSTS, whereas the browser does not accept other certificates or a downgrade to http.


3

When talking about security (in general), it is important to think about what problems you are attempting to solve, and what tools you are using to solve them. These have to align. If the problem you are attempting to solve is general attacks from the internet, then whitelisting may be a useful tool - to overcome whitelisting, you have to be somewhere on ...


3

The result of this attack is not really different from someone compromising your router, your ISP, your VPN endpoint or similar: the attacker will be able to intercept and modify the traffic. Depending on the way the attack is done and depending on the characteristics of the line (i.e. FTTH vs. xDSL vs. cable...) one might detect changes to the line ...


2

You seem to have some confusion about how communications take place in Internet. I suggest you to read: Internet (Wikipedia) But interesting to note, would be that the information you exchange over the network transit is small packets, through different nodes. The exact location of the nodes depends on many factors. But when Alice in LA use skype to ...


2

BGP hijacking is real and there are enough and easy to find reports in the internet, like this one or this one or this one. But of course you need to be at the right place to do it. Simple from your DSL connected system is not possible but you need to be at the level of ISP's which actually participate in BGP routing. Though you can still play with the ...


2

OS detection goes a lot further, using all kind of data of the IP and TCP headers fields. If you're into reading, "Silence on the Wire" by Michal Zalewski addresses a lot on this topic.


2

Yes, a https connection (TLS/SSL) will be secure against snooping by your VPN provider, although they will know the IP address of the website you're connected to, so they will be able to run reverse DNS and likely at least figure out what domain you went to.


1

You can run a local machine as the web proxy and point all others to use that for all http traffic. Squid is one option. Another option is to setup one machine to be the DNS server, e.g, using bind. You can then collect all the DNS logs. You can set up your router to give this local DNS machine as the primary DNS server via DHCP. Another way (albeit the ...


1

My suggestion is a little different to what you asked: Download the app Packet Capture from the Google Play Store and install it on your Phone. Start the app, skip the generation of the root certificate (or generate one - this will help you decrypt SSL traffic), and start a capture. You can then capture and analyze packets directly on your phone - ...


1

This could be a browser intelligence as well. Try browsing https://google.com in Chrome when Fiddler is on and decrypt https traffic option selected. The browser stops sending request saying - your connection is not private.


1

I don't believe this would provide any more protection then the normal double submit cookies. If an attacker can overwrite one cookie using an unsecured (https) subdomain, they could just as easily overwrite 2 cookies. The attacker in the senario would get a legitimate token and signed token value, they would embed both of those in the request, and write ...


1

The problem with naive double submit is that if the attacker could insert an attacker controlled cookie he could also set the CSRF token to this cookie and this way defeat the CSRF protection - because token and cookie match. This can be defeated if the attacker is not able to create a CSRF token and guess the matching verification cookie. This can be ...


1

Properly validating a certificate is a really complex matter. As with many things in crypto, it's best to leave this validation to a library instead of trying to implement it yourself. Typically, you'd ask your library to perform all the hard work and then check for any additional properties you are interested in afterward. As for the details: First, you ...


1

And you should make a lot of checks about the cerificate genuinity, i.e. to avoid MitM or false-issued certificate by "so-called stolen" CA key. Take a look and star at Perspectives Project to have a full picture


1

Wireshark alone does not do that, it can only watch the traffic if you already have knowledge of the keys/certificates in order for it to decrypt the traffic in the TLS connection. There is a type of proxy, a transparent proxy, that applications have to use because they sit on port 80/443 of the gateway and simply intercept all traffic. This would be the ...


1

To circumvent the proxy problem, there is ARP spoofing available. MiTM the ssl, there's sslstrip. There are loads of tutorials on how that works. If however the certificate gets validated, you will be out of luck. As Steffen pointed out in the comments, there is no way to make wireshark - being a passive sniffer- sniff active. Yet, the tutorial I linked ...



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