Okhttp how to prevent Fiddler capture https request:
Work with your server’s TLS administrator to adopt certificate pinning. Be careful: certificate pinning done wrong may prevent your app from being able to connect to your server when the server updates its certificates.
Related
I am currently working on GO app and I wanted to know how can I detect someone using reverse proxy apps such as Charles, Wireshark and Fiddler.
I tried to read about SSL-Pinning but I couldn't find anything useful.
Charles and Fiddler are no reverse proxies but forward proxies. TLS interception in such proxies can be detected based on the certificate returned - it will not be the original server certificate but one created by the server. And certificate validation will fail unless the proxy is specifically trusted by importing the proxies CA certificate. SSL pinning helps too since it expects the server to use a specific certificate or a specific CA - which the SSL intercepting proxy cannot provide.
Wireshark is no kind of proxy but passive packet capturing, i.e. it makes no changes to the traffic. Because it is passive it cannot be detected from inside the client application and SSL pinning would not help either. Wireshark can not decrypt TLS traffic though by its own - it would need to have the connection specific secrets from either inside the client application or inside the server application.
I have a setup which involves devices connecting to a server via web sockets. I'm experiencing a strange problem where they can connect to one test server without issues, but cannot connect to a different server (hosted on Azure).
I've installed Wireshark on both of them, and can watch both the successful connection and the unsuccessful connection. It appears that the unsuccessful one attempts to initiate an SSL handshake.
Here is the successful connection:
Here is the unsuccessful connection:
It seems like the client in the successful connection is simply setting up an HTTP web socket, but in the unsuccessful setup it's try to set up a secure connection.
Why would the client be setting up different connections depending upon the server address?
The client code to create the websocket is just javascript, invoking new Websocket(address), and in both cases the address begins with the 'ws' prefix.
I have done some further investigation and found another weird behavior. As it happens, there are two domain names pointing to the same server.
If I used the domain name with the top level domain "com" (XXXX.australiaeast.cloudapp.azure.com), then the connection works.
If I used the domain name with the top level domain "dev" (comutername.mydomainname.dev) then the connection fails, with the weird TLSV1 packet.
Both works fine if I run the same client code on the Microsoft Edge browser.
This appears to be a defect in Chrome's implementation of The WebScoket API
I have posted a defect here, let's see how it goes. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076
The issue in play here is HTTP Strict Transport Security (HSTS)
A browser can be configured so that certain domains have an HSTS policy attached, meaning any insecure link will automatically be converted to a secure link.
This policy will be applied if a request returns a Strict-Transport-Security header. But, and here's the significant bit, the Chrome and Firefox browsers automatically apply the policy to all dev domains.
It appears that up until recently, the Chrome browser and Chrome OS was not observing the policy with regard to WebSocket connections. This has changed, and now WebSockets will observe the HSTS policy.
The upshot is, if you have a websocket using the ws protocol and not the wss protocol, and it's on a .dev domain, your Chrome and Firefox browser will not be able to connect to it.
I'm trying to set up a proxy server on my local mac.
http - seems to work.
But Safari is not connecting via https.
Did I miss something?
No it doesn't. You need to specify a separate https port and a ssl certificate, as documented in the squid config:
The socket address where Squid will listen for client requests made
over TLS or SSL connections. Commonly referred to as HTTPS.
This is most useful for situations where you are running squid in
accelerator mode and you want to do the TLS work at the accelerator
level.
You may specify multiple socket addresses on multiple lines, each
with their own certificate and/or options.
The tls-cert= option is mandatory on HTTPS ports.
See http_port for a list of modes and options.
http://www.squid-cache.org/Doc/config/https_port/
By design, it is quite hard to intercept https traffic:
When a browser creates a direct secure connection with an origin
server, there are no HTTP CONNECT requests. The first HTTP request
sent on such a connection is already encrypted. In most cases, Squid
is out of the loop: Squid knows nothing about that connection and
cannot block or proxy that traffic.
You also need to load the proxy settings for the browser as a PAC file, otherwise the browsers won't connect or throw a certificate warning:
Chrome The Chrome browser is able to connect to proxies over SSL
connections if configured to use one in a PAC file or command line
switch. GUI configuration appears not to be possible (yet).
More details at
http://dev.chromium.org/developers/design-documents/secure-web-proxy
Firefox The Firefox 33.0 browser is able to connect to proxies over
TLS connections if configured to use one in a PAC file. GUI
configuration appears not to be possible (yet), though there is a
config hack for embedding PAC logic.
There is still an important bug open:
Using a client certificate authentication to a proxy:
https://bugzilla.mozilla.org/show_bug.cgi?id=209312
https://wiki.squid-cache.org/Features/HTTPS
Is it possible to have a Sinatra web server detect an HTTPS:// connection and redirect it to a HTTP:// connection with the same URL, and not have to deal with SSL certificates? I tried stunnel to redirect but it's asking for a cert.
With HTTPS, the first thing a browser does is to create a secure connection to the webserver. For this, it requires a valid server certificate. Before the secure connection is established, you can not perform any HTTP redirect yet.
Thus, to be able to perform any redirects from https to http, you need to have a valid SSL certificate on the server. And in that case, you should really think about having SSL enabled for all content anyway.
I was trying to make a website that require the user to log in to do something, but I want to know the advantage and disadvantage from HTTP and HTTPS first.
I was using a program called Fiddler that allowed you to logs all HTTP(s) traffic between your computer and the Internet
if I try to log in with the program on, I could see the username and the password that I used to log in to the website, even if it's HTTP or HTTPS using fiddler
so what's the use of HTTPS compared with HTTP?
This is what I am thinking.
The browser is supposed to enscrypt the password using the server's public key right? Then the server will descript it with the private key.
But fiddler doesn't know the server's private key. So how can it sees the plain password?
Am I wrong?
In HTTPS communication is sent over an encrypted channel, while HTTP is sent in plain-text. Most importantly his means that a 3rd party can't read information sent between the server and the browser just by sniffing network traffic, but it has other uses as well, such as ensuring that the server is who it says it is and you are who you say you are with certificates.
Fiddler2 is only able to decipher the traffic with the user's cooperation: the certificates Fiddler presents to the client are only trusted by the browser if you configure your Operating System to trust Fiddler's root certificate.