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
Related
Suppose I have a mobile app which makes API calls to a server using HTTPS.
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
If you control the client, then of course yes. Anything the client knows, its user may also know.
Without controlling the client, no, an external attacker cannot inspect or change https traffic unless they know the session keys. For that, they would typically use a fake certificate and make the client accept it (it won't do it by itself, and we are back at controlling the client).
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
Yes this possible if the user controls the device he wants to intercept the API calls.
In the blog post Steal that API Key with a Man in the Middle Attack I show how a proxy tool(MitmProxy) can be used to intercept and introspect the https calls:
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
In order to protect https calls from being intercepted, introspected and modified the solution is to use certificate pinning:
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
and you can learn how to implement it in the article Securing HTTPS with Certificate Pinning on Android:
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
While certificate pinning raises the bar, its still possible to intercept, introspect and modify https traffic, because it can be bypassed, as I demonstrate in the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Conclusion
While certificate pinning can be bypassed I still strongly recommend its use, because it will protect the https communication channel betwwen your mobile app and API server in all other scenarios where is not the user trying to perform the Man in the Middle attack:
In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unencrypted wireless access point (Wi-Fi[1][2]) could insert themselves as a man-in-the-middle.[3]
Going the extra mile?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
HTTPS request is encrypted on your host (client) before sending over the network, so it is not available for Wireshark. Wireshark can get hostname of the HTTPS web serserver you connect but not the URL.
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!
Am using IBM Worklight Studio 6.1.0.02-20160314-1430
Its Hybrid application.
Request and Response data between app and adapter calls is clearly getting visible when do inspect(Network-->query) in an application. Its also possible to edit request or response parameters by interrupting worklight app using third party tool like Charles. Implemented SSL pinning in the application but some how SSL pinning also breakable as lot of tools already available in online. Is Worklight giving any encrypt-decrypt mechanism for request and response parameters which is communicating between adapter and app.
Currently I tried adding custom encryption from app side and custom decryption at adapter side for request parameters. This is very tedious process as my app having hundreds of procedures. Please let me know any centralized security I can implement so that request and response should not be visible anywhere between app and worklight server even if someone inspect also.
When you redirect your traffic through a proxy such as Charles , it is expected to see communication in plain text. In this scenario you configure the setup by accepting certificates issued by Charles and modify your application to direct communication via Charles. You will not see your data in plain text if you try to sniff an on-going SSL traffic.
That said, certificate pinning feature is available out of the box starting MFP 7.1 onwards. Certificate pinning is done before making any calls to the server and as such all your communication can be secured.
You already seem to have adopted the other approach of encrypting parameters at the client and decrypting later at the server. In case you have many adapter invocations, you can have a single method that produces encrypted content and all your adapter invoke parameters can be passed through this.
I will build a cross platform application (WP8, IOS, Android) and those apps will use
my server to make API requests.
My server also will call different type of APIs (google, facebook, etc) and return some results.
And application owner does not has to be logged in to make those calls.
If there is man in the middle, he can track api calls and use it for his own usage drain my quota against api services I am using.
I only want phone who has application be able to make those calls.
What would be the best way to detect api calls to my server should come from my application?
You can use SSL to prevent man in the middle attacks but there really isn't a way that you can be 100% certain that you are communicating with your application.. You can make it harder to do by requiring some sort of access token or using custom encryption but if somebody can decompile your app they can do whatever they want.
In your specific case you should use HTTPS and in the client, not only check that you are using an HTTPS connection, but that the certificate presented by the server and its certificate chain are the ones you expect.
If you fail to do so, you could still perform a MITM attack. For example:
The MITM proxy could act as the client to the server and use an HTTP connection to serve the contents to the real client.
The MITM proxy could act as the client to the server and use a self-signed SSL certificate to present the real client an HTTPS connection.
I'm implementing an SSL layer for a web server project. I'm using polarSSL, though I think this question is a general SSL question.
When I get a connection to my server from a client I configure the SSL protcol like this:
ssl_set_endpoint( &mSsl, SSL_IS_SERVER );
ssl_set_authmode( &mSsl, SSL_VERIFY_NONE );
E.g. I'm not verifying the connection from the client. Do I need to do this?
Most browsers don't have client side certificates - though some do (I think). Is there any need or advantage for the server to verify the client? This is for a service where I would happily serve the data to a client that had no client side certificate at all.
Client-side authentication in SSL/TLS is used when it's required for the server to know its client. For example, it's widely used in banking, to access custom corporate servers etc.
In opposite, the common web server is intended to serve wide audience and not care about who's coming in. So client-side authentication is not used unless you know that you need it.