I set up Burp to intercept https requests. I could see the packets of all https websites like goole, facebook. The website web.whatsapp.com is not loading completely on using with Burp proxy. I am getting this error on webpage
WebSocket connection to 'wss://web.whatsapp.com/ws' failed: WebSocket
opening handshake timed out
What may be the reason?
Like many popular apps, WhatsApp is using certificate pinning which makes sniffing packages way more difficult (as the application only trusts one certificate). That being said Burp Suite offers some solutions for iOS, which unfortunately only work if your device is Jailbroken (If this is the case here is what you have to do).
I hope this helps!
Related
When I run an IOS App through proxy using tools such as Charles, Burp suite and Proxyman I'm not able to see the full request (receiving 403 when SSL is enabled) of the final end point after loged in, and also the App just stop working(Just work when SSL is disabled). I would like to see what the full request looks like to do it using Postman and HttpClient in Java. Is there anything I could do in order to get status 200 like when SSl is disabled ?
Any help to try bypass it is appreciated.
This is probably due to TLS fingerprinting.
Platforms like Cloudflare offer services to block bots and other non-browser traffic, which analyse low-level details of how a client makes connections, including the TLS fingerprint, and use this to spot unusual traffic. Because proxies like the ones you're using create separate upstream TLS connections when they intercept incoming connections, they can often end up sending HTTPS traffic where the TLS fingerprint the server sees doesn't match the HTTP headers, which is sufficient for the connection to be blocked as 'unusual'.
Defeating this is not easy. I also maintain an HTTPS debugging proxy called HTTP Toolkit, where I've done some work to defeat this, by optimizing individual fields of TLS handshakes to avoid common blocks (some more details: https://httptoolkit.tech/blog/tls-fingerprinting-node-js/). You might have more success using HTTP Toolkit in this case, since it can successfully avoid 90% of these kinds of blocks at the moment.
(Note that HTTP Toolkit doesn't have automated setup for iOS yet, but you can still use it manually like any other debugging proxy - you just need to trust the certificate & set your proxy settings)
That said, this still won't work 100% of the time. This is a cat & mouse game between bots and site-scrapers and bot-blocking services, where the criteria are constantly changing & tightening, so there is no perfect solution. Your best bet is to keep trying different tools, and see which ones can make themselves look least suspicious while proxying your traffic.
By watching Computerphile YouTube videos, I know that today's browsers perform a TLS Handshake with every HTTPS website they display for me on my PC. For this question, let us assume the request is pointed at my server, running an Express API, protected by a valid SSL certificate. Will a TLS Handshake be performed even when I send a POST request with the help of:
Requests module in Python, a simple POST request to my server from a Python script.
NodeJS (Express.JS), a simple POST request (containing username and password) from a HTML webpage to my server.
From a mobile app programmed in MIT App Inventor 2, which gives me an option of making a POST request.
... and not a browser?
I am asking this question in regards to an app I am programming, wherein the user has to identify himself with a key and a password, and I want the information (log-in and else) to be securely conveyed to my VPS.
HTTPS means HTTP inside TLS. This means accessing a https:// URL always requires also TLS and thus a TLS handshake. It does not matter if the client is a browser, Python code, NodeJS or whatever. It does not matter if it is GET or POST request either.
I have an android app with few apis that has SSL. When i try to do packet sniffing using Fiddler2 or charles proxy after installing a trusted certificate on my device, I've been able to see all HTTPS calls.
I made a few tests in other apps to see if its normal and found some of them won't show or connect to the ssl request. How can i avoid being showing my APIS on packet sniffing. I am using lets encrypt on my domain for ssl
This is not possible and it also shouldn't be necessary.
It is impossible to tell whether a device along the path between client and server is sniffing packets. Thus you will not be able to kill the connection based on whether someone is sniffing somewhere. This is the equivalent of looking at a downloaded file on your computer and wondering how many other copies there are in the world. Neither the file nor your receipt thereof stores this data.
It should also not be necessary as HTTPS is immune to MITM provided you are not a state-level actor. This is unless you have access to the client, in which case you can add your MITM as a trusted CA. For more info on HTTPS and MITM attacks, you should take a look at Kazakhstan's past attempt at it
I have seen many implementations of certificate pinning for HTTPS connections originated from client-side apps running on mobile devices using native libraries and plugins.
I would like to know whether such certificate pinning implementations are available for websockets. In the client side (say a mobile device or web browser), can we actually implement certificate pinning for websockets?
If such approach is available, it would be really nice to have an explanation, ideally with links to resources/ articles/ code snippets/ libraries.
With web sockets it is possible to send HTTP headers.
HTTP Public Key Pinning (HPKP) is an Internet security mechanism delivered via an HTTP header which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise
HTTP Public Key Pinning is just a HTTP header on the server side.
On the client side, which really depends on the language/runtime, you might have to implement it yourself.
When talking about a browser as a client:
the initial attempt to establish the websocket connection still happens over a standard HTTP request and requires a standard HTTP request to be properly established. As a result, the browser should still respect any response headers sent back down by the websocket server when initially establishing a connection.
StackExchange - Information Security: Certificate Pinning for WebSockets
I would like to know if there is an option to implement secure websockets (wss://) and client certificate based authentication with twisted ?
I followed the instructions on http://twistedmatrix.com/documents/12.3.0/core/howto/ssl.html, in which the setup of a site over https:// and client certificates is described. Using self signed certs, this works fine. However, things get tricky when Websockets come into play.
Running the whole thing in IE 10 works fine. The client authenticates with his certificate and gains access to the site and may open the Websocket. FF and Chrome, however, won't work. Note that webserver and websocket run on the same port.
In my opinion, it seems that IE somehow stores the authentication of the client and uses it as well for the access to the websocket. FF and Chrome somehow treat the websocket as a different ressource for which no authentication has happened before.
Has anybody experienced the same or somewhat similiar issues or maybe implemented a solution for this?
If needed, I can provide my source code so far.
For all interested readers having the same problem, I finally figured it out.
The solution is to set a session id for the ssl context. Then the browser seems to remember the cert authentication even for subresources like websockets.
This should do it:
contextFactory = twisted.internet.ssl.DefaultOpenSSLContextFactory('keys/server.key',
'keys/server.crt')
ctx = contextFactory.getContext()
ctx.set_verify(
OpenSSL.SSL.VERIFY_PEER | OpenSSL.SSL.VERIFY_CLIENT_ONCE,
verifyCallback
)
## Since we have self-signed certs we have to explicitly
## tell the server to trust them.
ctx.load_verify_locations("keys/ca.crt")
ctx.set_session_id("id")
Lines 1-8 are needed anyway. Whats new is line 9. Here you have to set a session id.
As you've described the issue, this is simply a browser bug, and there's not much you can do about it with Twisted.
Websockets are still, sadly, a somewhat immature technology and bugs like the ones you're seeing are still being worked out. File bugs against the browsers and hope that they get fixed.
Perhaps you could consider implementing server-sent events for non-IE browsers, assuming that the client-cert-auth stuff works for that API / protocol?