Well, the title says it all. For testing purposes I need that each SSL session will renegotiate its encryption parameters. Can I configure Fiddler in such a way to always decline a client's request to reuse previously negotiated encryption params, and force it to negotiate new ones?
Unfortunately, I don't know any way to force SChannel (the stack under System.Net.Security's HTTPS implementation) to do that.
One quick thing to remember is that when you have HTTPS decryption enabled there are two HTTPS connections in this scenario-- one from the client to Fiddler and one from Fiddler to the server.
Related
From my understanding, each browser implement tls/ssl themself, which mean when user open a https website from a browser, the browser is responsible for encrypt the request.
So is it possible to make a browser or any other type of client that doesn't implement tls/ssl and therefore will make https without encryption? And if yes, then how ?
... client that doesn't implement tls/ssl and therefore will make https without encryption?
HTTPS is HTTP inside a TLS connection. This means a client which does not implement SSL/TLS will not be able to make a HTTPS connection in the first place by the very definition of what HTTPS is.
It might in theory be possible though that TLS is used without encryption, i.e. only with authentication and integrity check. Up to TLS version 1.2 there were the NULL ciphers which made this possible. In practice no sane server will implement this. If the client still tries to use such cipher the TLS handshake will fail since there is no common cipher between client and server.
See also Unencrypted SSL protocol?.
The typical scenario:
The client sends his credentials to the server in a POST request using HTTPS.
The server verifies that the credentials are the right ones and authenticates the user. Thus it returns a JWT (JSON Web Token) to the client.
The client opens a non secured WebSocket connection (ws://). So the client and the server now have a channel to exchange data easily (the exact reasons don't matter here).
The user sends any kind of requests to the server through the WebSocket along with the JWT, so the server can verify that these requests are legit.
The server uses the WebSocket channel to return the data asked by the user after it successfully verified the JWT for each request.
Since we used HTTPS, we assume the JWT was not stolen when it was issued (HTTPS could be defeated but let's assume it's sane for our purpose).
The fact that we use a non secured WebSocket means that someone could sniff the traffic of the WebSocket channel and steal the JWT in a heartbeat. So we use a WebSocket Secure (wss://) instead and apply the same previous scenario.
Now that we are using a WebSocket Secure, do we need to keep sending the JWT in each request we make to the server when we use the WSS channel to do so? Or is the WebSocket Secure channel secured enough so both the server and the client are 100% sure (as long as TLS is not defeated) that this channel is legit?
In other words: once a WSS channel has been safely established, can we trust it? (until the connection is closed obviously)
I don't really understand how a WSS connection is established and how it works once it has been established. My understanding is: the critical part is the handshake, and once the handshake is done you can safely rely on the WSS channel (because it prevents MITM attacks using TLS, which WS doesn't do).
I read a lot of stuff these last days about all this but some concepts are still unclear. Any help will be greatly appreciated!
Websockets use a persistent TCP/IP connection.
Using wss is similar to using the HTTPS, which means that once the SSL/TLS handshake is complete, all Websocket data is "wrapped" (usually encoded) in TLS packages.
Assuming the TLS/SSL connection is secure, the Websocket connection will remain secure and could be (and probably should be) authenticated only once.
Hence, there's no reason to keep sending the JWT over and over again. It's a better solution to use the connection's persistent state in order to "assign" a user to the connection.
Side-Note: Although insecure, it would be better to send the JWT once even when using Websocket connection "in the clear" (ws://), since there are less opportunities to sniff out the JWT.
is there a way for some one to sneak in the to see data if my service is over http and the caller in my case is hosted on http (i.e. service is on secure ssl host while caller is on simple http).
is that call secure or not?
Basic HTTP without any encryption or other means of obfuscating your content is just plain text going over the wire. Anyone with a bit of knowledge can trap that connection and just read everything that goes on.
I don't quite understand what you mean by the server is on secure host but the client is not? Either the conversation between those two is secured by SSL / HTTPS (but then BOTH ends need to participate), or not. If not - it's just clear text on the wire.
Yes if someone is able to sneak into your transmissions, they can workout if the messages are encrypted or not.
When you connect to a server marked with server side SSL (server marked with https), it sends a copy of its cert to the client (e.g. your browser) which verifies if its a genuine cert. This only confirms that the server is really what it says it is and not someone else masquerading.
This does not guarantee that no can intercept your message. They can intercept but wont be able to decrypt.
I apologize before hand if this is an obvious question: can Apache 2.0 + SSL + basic authentication be trusted in order to secure a website? The way I see it, SSL creates a secure connection between the client and the server and thus any HTTP requests containing the clear-text password should not be a security issue.
thanks,
S.
You are correct, basic auth is secure as long as you can guarantee the connection is end-to-end encrypted. This means that you must configure the server to force SSL usage by redirecting HTTP requests to HTTPS, or not accept unencrypted connections at all for that URL.
"The only fully secure computer is one that is unplugged and turned off"
That said, Jim's answer is Good Enough if you accept SSL level of security :)
What is difference between https protocol and SSL Certificate that we use in web browser?
Aren't both of these used to encrypt communication between client (browser) and server?
HTTPS is HTTP (HyperText Transfer Protocol) plus SSL (Secure Socket Layer). You need a certificate to use any protocol that uses SSL.
SSL allows arbitrary protocols to be communicated securely. It enables clients to (a) verify that they are indeed communicating with the server they expect and not a man-in-the-middle and (b) encrypt the network traffic so that parties other than the client and server cannot see the communication.
An SSL certificate contains a public key and certificate issuer. Not only can clients use the certificate to communicate with a server, clients can verify that the certificate was cryptographically signed by an official Certificate Authority. For example, if your browser trusts the VeriSign Certificate Authority, and VeriSign signs my SSL certificate, your browser will inherently trust my SSL certificate.
There's some good reading here: http://en.wikipedia.org/wiki/Transport_Layer_Security
Two pieces of one solution.
https is the protocol that defines how the client and server are going to negotiate a secure connection.
The SSL Certificate is the document that they will use to agree upon the servers authenticity.
HTPS is the new HTTPS.
HTTPS is highly vulnerable to SSL Stripping / MITM (man in the middle).
to quote adam langley's (google) blog imperial violet:
"HTTPS tends to cause people to give talks mocking certificate security and the ecosystem around it. "
The problem is that the page isn't served over HTTPS. It should have been, but when a user types a hostname into a browser, the default scheme is HTTP. The server may attempt to redirect users to HTTPS, but that redirect is insecure: a MITM attacker can rewrite it and keep the user on HTTP, spoofing the real site the whole time. The attacker can now intercept all the traffic to this perfectly well configured and secure website.
This is called SSL stripping and it's terribly simple and devastatingly effective. We probably don't see it very often because it's not something that corporate proxies need to do, so it's not in off-the-shelf devices. But that respite is unlikely to last very long and maybe it's already over: how would we even know if it was being used?
In order to stop SSL stripping, we need to make HTTPS the only protocol. We can't do that for the whole Internet, but we can do it site-by-site with HTTP Strict Transport Security (HSTS).
HSTS tells browsers to always make requests over HTTPS to HSTS sites. Sites become HSTS either by being built into the browser, or by advertising a header:
Strict-Transport-Security: max-age=8640000; includeSubDomains
The header is in force for the given number of seconds and may also apply to all subdomains. The header must be received over a clean HTTPS connection.
Once the browser knows that a site is HTTPS only, the user typing mail.google.com is safe: the initial request uses HTTPS and there's no hole for an attacker to exploit.
(mail.google.com and a number of other sites are already built into Chrome as HSTS sites so it's not actually possible to access accounts.google.com over HTTP with Chrome - I had to doctor that image! If you want to be included in Chrome's built-in HSTS list, email me.)
HSTS can also protect you, the webmaster, from making silly mistakes. Let's assume that you've told your mother that she should always type https:// before going to her banking site or maybe you setup a bookmark for her. That's honestly more than we can, or should, expect of our users. But let's say that our supererogatory user... ]
because of obstructing/very stupid link-rules for new users on stackoverflow i cannot give you the rest of adam's answer and you'll have to visit adam langley's blog yourself at
https://www.imperialviolet.org/2012/07/19/hope9talk.html
"Adam Langley works on both Google's HTTPS serving infrastructure and Google Chrome's network stack."
HTTPS is an application layer protocol. It can provide non-repudiation of individual requests or responses through digital signatures.
SSL is a lower level protocol and does not have this capability. SSL is a transport level encryption.
HTTPS is more flexible than SSL: an application can configure the level of security it needs. SSL has fewer options so it is easier to setup and administer.