I read many articles cookies are passed over HTTPS connection is encrypted.
I checked with my application, its having SSL connection, but i can read cookie information from request headers. Is anything done for cookie encryption in HTTPS connection?
HTTPS encrypts the entire session, headers included.
But notice that SSL (TLS in fact) works over the Transport Layer. If you are reading the cookies from the Application Layer (for example using javascript or a java servlet to get the HTTP request) the content will be already unencrypted.
See Does SSL also encrypt cookies?
Related
A different thread pointed out a couple of services that would require a client MTLS certificate, accept any cert, and then respond with information about the SSL handshake/certs.
HTTPS test server that checks client certificates
These endpoints both return HTML. Does anyone know of anything similar that returns application/json?
The URLs below will return application/json content upon successfully mutual TLS client certificate authentication. If no authentication is peformed, then HTTP error 403 is returned in the HTTP headers and the response is empty:
https://certauth.idrix.fr/json (TLS 1.2 only)
https://certauth.cryptomix.com/json (TLS 1.2 and TLS 1.3)
The json returned in case of success contains various technical information about the established connection.
can the proxy server intercept my https request and set cookies before actually sending the request?
I'm going a GET on an url from chrome browser. In the development tools, under "Network", I noticed that the first request, the one that I made, has cookies set. but I did not set any cookies.
any thoughts?
No it can't. To proxy HTTPS requests your browser issues HTTP CONNECT command (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT). Proxy then creates a tunnel between the browser and a target server.
A conventional proxy can neither view nor manipulate a TLS-encrypted data stream, so a CONNECT request simply asks the proxy to open a pipe between the client and server. The proxy here is just a facilitator - it blindly forwards data in both directions without knowing anything about the contents. The negotiation of the TLS connection happens over this pipe, and the subsequent flow of requests and responses are completely opaque to the proxy.
It cannot modify or see what is being transferred as it is protected by TLS encryption.
The only way to modify HTTPS conenctions on the fly is if you install some external CA certificates on your computer. This is known as MITM Attack.
I am new to web services and read about token based authentication which can be used with web services from What is token based authentication?. I searched on internet but its quite confusing how http based websites manage to do token based authentication without any security vulnerability.
What point I have?
I can sit in between server and client and store the token somehow by sniffing the traffic and make misuse of it before it expires. Am I wrong here?
EDIT
As mentioned on https://security.stackexchange.com/questions/46348/token-based-authentication-under-http.
"Facebook uses an OAuth token passed as a cookie or HTTP header and
protected by HTTPS."
How can I implement this as in that case the website will be http-based and only http-headers will be using https. Please correct me if I am wrong.
Your edit suggest a misunderstanding of what HTTPS does.
Normatively speaking, HTTP (meaning, the "language" that is spoken on the network, defined by https://www.ietf.org/rfc/rfc2616.txt) is a text based, "application level protocol", used over TCP sockets (TCP being the "transport level" layer).
In that sense, HTTP and HTTPS are the same "language", nothing differs in them. HTTP and HTTPS are both text based request/response protocols, each consisting of headers and an body, with requests specifying a verb such as GET, POST, PUT, ... No difference whatsoever.
What is different in HTTP vs. HTTPS, is that underneath this HTTP "language" (application level protocol), HTTPS uses TCP sockets that are encrypted using a SSL or TLS layer that provides encryption.
As the SSL/TLS layer happens under the HTTP layer, there can be no difference between what happens to the headers of a request and what happens to the body.
Back to your question :
How can I implement this as in that case the website will be http-based and only http-headers will be using https. Please correct me if I am wrong.
You can't have only the headers, and not the body using HTTPS in a single request/response cycle. It's all or nothing.
The conclusion is, as per the article you link to : token based authentication can only be secure if the token is always secured. Which, if you are always using HTTPS (in all request/response), is guaranteed (both the headers and the body are protected). If even one single request or response is not sent over HTTPS, then you have a flaw.
On the doc Specifying WebSocket authentication details, it did not mention how are passwords being sent from client's authenticate() JS func to server's onWSAuthenticate. Are they being sent through a secure channel? or in plain text?
Side question: what tool / browser / browser's plugin can one use to sniff through websocket's traffic?
Thank you.
username/password sent through authenticate() function is in clear-text. You can actually see that in cfwebsocket.js (its minified so search for authenticate). On server if the call is for authentication, it would invoke onWSAuthenticate() in application.cfc passing whatever username or password given to the function. So the logic of encryption/decryption/validation lies with the developer.
Any TCP monitor can be used for sniffing websocket's traffic like wireshark , TCPMon etc
Mostly just answering to further my own understanding of how this works. From the websocket.org site:
The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT technique.
So, if this is what you're asking, it appears that just like with http/https, it's up to the developer to implement SSL encryption, which makes sense.
Sagar Ganatra also has a blog entry on the basics of Websocket Authentication with CF.
I understand, we use SSL to encrypt sensitive data like user name and password to transported to server without people in the network eavesdropping. So then server returns a secure token over HTTPS and its stored in cookie. We switch to HTTP after we have secure token, we attach cookie/secure token header to every HTTP request.
Now anybody can see my secure token and they can eavesdrop it and impersonate me. Is my understanding correct?
The cookies can be set per protocol, so that HTTPS cookies are not used for HTTP and vice versa. Also, the properly constructed secure token should include an IP address and have short expiration time.
But in general the best idea is of course to keep the authenticated session in secure channel - SSL is not that heavyweight these days (as computers became much faster than when SSL was first introduced) and also the heaviest part is handshake, which is performed only once if persistent HTTP connection is used (or when SSL session resuming is used).