What displayfilter to use to see http to Https redirect.
Example. I visit http://www.google.com/ and I am redirected to Https://www.google.com/. Where can I see that redirect?
Example. I visit http://www.google.com/ and I am redirected to Https://www.google.com/. Where can I see that redirect?
Okay, that's a tricky combination. Let's see, we have:
Since the filter has to hit on the response, we have no access to the original request. But we do know it's to an HTTP address, so we may assume the server TCP port used is 80.
The redirect is done with the HTTP response code 302. That is clearly present in the response.
The redirect also must contain a HTTP location header, which according to the stated question, must have "https://" in the address.
Using this combination I would probably arrive at this filter:
(tcp.srcport == 80) && (http.response.code == 302) && (http.location contains "https://")
Hello, Thanks for the response, but it is not working for me. Maybe I'm doing something wrong. I type http://www.google.com/ and I get redirected to https://www.google.com/. U applied your filter but I dont see any packets.
Are you certain that there is a redirect?
I ran Wireshark and then typed "http://www.google.com" into my browser, but I don't see any HTTP-over-TCP traffic to www.google.com - it appears that the browser tried HTTP-over-TLS without trying HTTP-over-TCP first. (That even happens if I try http://www.google.com:80!)
Perhaps Safari either just tries HTTP-over-TLS first for all attempts, or remembers that it's used HTTP-over-TLS in the past for www.google.com and tries it first? Perhaps your browser does the same?
Then Can I detect Http over tls?
tcp.port == 443
will probably 1) detect most HTTP-over-TLS packets and 2) not detect many non-HTTP-over-TLS packets (I'm counting TCP ACKs to HTTP-over-TLS data - and the initial 3-way handshake setting up a connection over which HTTP-over-TLS will be sent - as HTTP-over-TLS packets).
I'm trying to setup proxy which will drop packets that redirect http to https.
Those won't be HTTP-over-TLS packets - they'll be packets that cause HTTP-over-TLS to be done.
And if there is no redirection - if the initial connection is done using TLS - there will be no redirect and thus nothing for your proxy to drop.
What is the ultimate purpose of this proxy? Perhaps you'll have to achieve that ultimate goal in some fashion other than dropping packets that cause the redirect.
Purpose of this proxy is to sniff TLS data. Target requests website in http, website redirects to https but I drop this packet and I (attacker) continue to communicate with website and then I send response to target. Target thinks that he is connected to website, but in reality I'm connected to real https website. It will allow for sniffing traffic. This attack I think is called reverse SSL proxy.
Example. TARGET access http://www.google.com/ so it sends get request. ROUTER responds with redirect to https but I drop this packet, and send the same request to https website. ATTACKER receives html code of website, and then I'm sending it to TARGET. This allows me to sniff https data becouse target thinks that it is connected to http.
Please start posting anonymously - your entry will be published after you log in or create a new account.
Asked: 2018-12-09 08:19:25 +0000
Seen: 7,749 times
Last updated: Dec 09 '18