I'm in the process of putting my whole website behind SSL because something requires it right now. It's the first time I do that. I normally debug my (php/asp.net) website via Wireshark, and I really worry about the fact this will be totally obscure/encrypted once running in SSL.
Should I say goodbye to fast, simple debugging with a packet sniffer, or there are well-known practices to debug it?
You can decrypt (some) SSL traffic with WireShark. Since you own the domain, you own the private key the site will use. Configure WireShark to use it to decrypt the traffic to/from your site.
http://wiki.wireshark.org/SSL/
https://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/
Related
I have recently been sharing the connection of my mobile device to my laptop, when i'm out and about, through the use of an app called netshare. It provides a https proxy I believe through which it acts as a network repeater?(not sure about this part). I can access webpages and such quite easily. However, I have realised that I cannot connect to some apps. For example, I cannot use spotify. Installing some other apps like games etc also prove to fail. I have done a bit of research and found that apparently I could only surf the web with a https proxy. However, I found this to be unambiguous. Does this mean that I can only make https requests? Or is this because of https using TCP over UDP? What are the limitations and what can I do to possibly solve it?
Thanks
I'm trying to use wireshark to decode, view, and ultimately log my own https traffic--response bodies included. According to the wireshark docs, I need provide the file location of the private RSA key used to decode messages. My question is this:
Where on osx is the private rsa key used in https interactions, is this a single key? Many?
Wireshark docs seem to be telling me to make an RSA key. Given that I'm not experienced enough with this topic, messing with system keys because I read a thing on the internet seems like a pit of despair. What should I do?
What I'm really trying to do is log unencrypted https requests/responses with bodies, while listening to web traffic. If there's a better way I'm all ears.
What I'm really trying to do is log unencrypted https requests/responses with bodies, while listening to web traffic. If there's a better way I'm all ears.
Don't mess around with Wireshark for this. The documentation you're reading is outdated; modern TLS cipher suites do not use pure RSA for key exchange. This configuration was only supported by SSL 2.0, which was superseded by SSL 3.0 in 1996, and is no longer supported by any moern browser. Long story short -- it doesn't actually work in practice.
Instead, use a HTTPS proxy server. Several common tools for this purpose are:
mitmproxy
Charles Proxy (commercial)
fiddler
Many of these tools will also allow you to alter the contents of an HTTPS session, which is certainly not something that Wireshark will do.
i'm too beginner in squid. i want a way to remain anonymous over the net. i also want to be able to access the contents of the internet which are filtered. my Windows computer is beyond firewall (filtered). my server (CentOS 5) is not. for example, when i enter http://facebook.com in the browser url, it redirects to an intranet ip which tells me to avoid going to this site!
now i've installed squid on server and traffic is propagated through this server. but this redirection occurs. so still i can't open filtered sites.
what can i do? a friend of mine told that the only way is to use https. ie. the connection between browser (Firefox) and the server must use this protocol. is it right? and how can i do that?
what's your suggestion? i don't want necessarily to use squid. besides, https protocol gets banned or decreased in speed in my country sometimes. so i prefer the protocol remain http. i thought also about writing a code in client and server to transform, compress/decompress and packetize as hoax binary http packets to be sent as much speed and success as possible. but i'm not an expert in this context and now i prefer more straightforward ways.
i respect any help/info.
I assume you are located in Iran. I would suggest using TOR if you mainly access websites. The latest release works reasonably well in Iran. It also includes an option to obfuscate traffic so it is not easily detectable that you are using TOR.
See also this question: https://tor.stackexchange.com/questions/1639/using-tor-in-iran-for-the-first-time-user-guide
A easy way to get the TOR package is using the autoresponder: https://www.torproject.org/projects/gettor.html
In case the website is blocked, it works as follows:
Users can communicate with GetTor robot by sending messages via email.
Currently, the best known GetTor email address is gettor#torproject.org.
This should be the most current stable GetTor robot as
it is operated by Tor Project.
To ask for Tor Browser a user should send an email to GetTor robot
with one of the following options in the message body:
windows: If the user needs Tor Browser for Windows.
linux: If the user needs Tor Browser for Linux.
osx: If the user needs Tor Browser for Mac OSX.
I am using a third party (OS X) tool to help me process OFX financial data. It works, but I am interested in knowing what exactly is going on behind the scenes to make it work (the structure of the HTTP requests).
I setup Charles as an SSL proxy for all traffic in hopes that I could observe the requests being made by this tool, but the program runs and Charles gets nothing. No requests show up whatsoever. How is that possible? Is there something I am not understanding about how Charles or other packet sniffing tools work? What are some ways that web requests could be made that wouldn't show up in a tool like Charles?
Charles is not a packet sniffer. It's a proxy. The app initiating the connection has to "voluntarily" use the proxy for the proxy to see anything. If an app uses a high-level networking API like NSURLConnection then it will, by virtue of the frameworks, automatically pick up the system-wide proxy settings and use the proxy. If, instead, the app wrote their networking using low-level socket API, then they will not end up going through the proxy unless they specifically re-implement that functionality.
If you want to see everything, you will need a real promiscuous-mode packet sniffer, which Charles is not. Unfortunately, using a "real" packet sniffer will just show you the gibberish going over the wire for SSL connections, so that's probably not what you want either. If an app has "in-housed" its SSL implementation and is not using a properly configured system-wide proxy, sniffing its traffic unencrypted will be considerably harder (you'll probably have to use a debugger or some other runtime hooking approach.)
This might sound really naive but I would really find a descriptive answer helpful.
So, my question is this:
I can use Firebug to look at AJAX requests made from any website I visit. So, am I right in saying that I wouldn't be able to examine the same communication between the client and the server if the website choses to use Websockets? In other words, does this make it more secure?
No. Not at all. Just because the browser does not (yet) have a tool to show WebSocket traffic, doesn't make it any more secure. You can always run a packet sniffer to monitor the traffic, for example.
No, because there will be other ways beside the browser-build in tools to read your traffic.
Have a try: Install and run Wireshark and you will be able to see all packets you send and receive via Websockets.
Depends on the application. If you are fully Ajax without reloading the document for data then I would think websockets would provide a better authentication for data requests then a cookie session in regards to connection hijack. Given that you are using SSL of course.
Never rely on secrecy of algorithm cause it only gives you false sense of security. Wiki: Security by obscurity
Remember that browser is a program on my computer and I am the one who have a full control over what is send to you, not my browser.
I guess it's only matter of time (up to few months IMO) when developer tools such as Firebug will provide some fancy tool for browsing data send/received by WebSockets.
WebSockets has both an unencrypted (ws://) and encrypted mode (wss://). This is analogous to HTTP and HTTPS. WebSockets protocol payload is simply UTF-8 encoded. From a network sniffing perspective there is no advantage to using WebSockets (use wss and HTTPS for everything at all sensitive). From the browser perspective there is no benefit to using WebSockets for security. Anything running in the browser can be examined (and modified) by a sufficiently knowledgeable user. The tools for examining HTTP/AJAX requests just happen to be better right now.