In HTTPS, only server hold the private key and is able to decode the message.
My doubt is whether server will encode the response before sending it to client?
If so, how does the client decode it, since it does not have the private key?
If not, how does it prevent others from tampering the response message?
I think I can answer my question by myself. The server will encrypt the response with public-key and send it to client. Other than that, the server will send a checksum as well, which acts as the signature. The checksum is generated based on the private-key that only server knows, therefore it is hard for others to fabricate it. Thus, if anyone trying tampering the message, it won't match the checksum.
Related
When a user tries to browse webpage having an invalid certificate(expired,self-signed, untrusted root, etc..),
browser warns the user about the security issue with page give option to proceed or return back.
Is it possible the change the page(default) that's being displayed here? how to get into the chain of event that gets trigger after the browser evaluates certificate validity?
Any help would be appreciated.
thanks,
It is impossible to achieve that feature on the server-side. It is a part of the client-side's browser implementation on validating the server-side’s certificate.
As you know, the Https connection based on the SSL/TLS version between the client-side and the server-side. establishing the TLS connection requires a handshake between the server-side and the client-side.
The client and server will provide the available TLS version during the process, including the supported certificate encryption algorithm and certificate public key. If the process fails, we cannot program the webpage displayed on the client-side since the TLS connection has not been established yet.
Feel free to let me know if there is anything I can help with.
The following is quoted from RFC6455 - WebSocket protocol.
Servers that are not intended to process input from any web page but
only for certain sites SHOULD verify the |Origin| field is an origin
they expect. If the origin indicated is unacceptable to the server,
then it SHOULD respond to the WebSocket handshake with a reply
containing HTTP 403 Forbidden status code.
The |Origin| header field protects from the attack cases when the
untrusted party is typically the author of a JavaScript application
that is executing in the context of the trusted client. The client
itself can contact the server and, via the mechanism of the |Origin|
header field, determine whether to extend those communication
privileges to the JavaScript application. The intent is not to prevent
non-browsers from establishing connections but rather to ensure that
trusted browsers under the control of potentially malicious JavaScript
cannot fake a WebSocket handshake.
I just cannot be sure about what the 2nd paragraph means, especially the italic part. Could anyone explain it a bit? Or maybe an example.
My understanding so far is like this:
If server CAN be sure that requests DO come from Web pages, the ORIGIN header can be used to prevent access from un-welcomed Web pages.
If server CANNOT be sure that requests come from Web pages, the ORIGIN header is merely advisory.
Your understanding seem to be correct, but..
I would rephrase it - you can be sure, that javascript client will send proper origin header. You don't know what will be sent by other clients (and whether the value is correct or not).
This should prevent other pages to connect to "your" web socket endpoints (which is a big deal, imagine injected javascript somewhere on jsfiddle or some frequently visited page), but if you need to make sure that no other client will be able to connect to it, you'll need to introduce some other security measures.
I believe this is meant only as prevention of browser based "data stealing" or "DDoSing", nothing else; you can still do that by using some other client.
Is it ok to pass passwords like this or should the method be POST or does it not matter?
xmlhttp.open("GET","pas123",true);
xmlhttp.send();
Additional info: I'm building this using a local virtual web server so I don't think I'll have https until I put upfront some money on a real web server :-)
EDIT: According to Gumo's link encodeURIComponent should be used. Should I do xmlhttp.send(encodeURIComponent(password)) or would this cause errors in the password matching?
Post them via HTTPS than you don't need to matter about that ;)
But note that you need that the page which sends that data must be accessed with https too due the same origin policy.
About your money limentation you can use self signed certificates or you can use a certificate from https://startssl.com/ where you can get certificates for free.
All HTTP requests are sent as text, so the particulars of whether it's a GET or POST or PUT... don't really matter. What matters for security in transmission is that you send it via SSL (and handle it safely on the other end, of course).
You can use a self-signed cert until something better is made available. It will be a special hell later if you don't design with https in mind now :)
It shouldn't matter, the main reason for not using GET on conventional web forms is the fact that the details are visible in the address bar, which isn't an issue when using AJAX.
All HTTP requests (GET/POST/ect) are sent in plain text so could be obtained using network tracing software (e.g. Wireshark) to protect against this you will need to use HTTPS
I don't understand the meaning of "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in RFC 6455.
Why does the server need this magic string?
And why does the WebSocket protocol need this mechanism?
The RFC explains it. It is a GUID, selected because it is "unlikely to be used by network endpoints that do not understand the WebSocket Protocol". See RFC 6455.
If you're interested in the specifics of the format for GUIDs like that, see RFC 4122.
From the Quora answer:
There is no reason for choosing the magic string. The particular magic string GUID was chosen to add some level of integrity to the WebSockets protocol, because the string is globally unique.
The RFC (RFC 6455 - The WebSocket Protocol) only says:
...concatenate this with the Globally Unique Identifier (GUID,
[RFC4122]) "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form,
which is unlikely to be used by network endpoints that do not
understand the WebSocket Protocol.
Hope that answers your question.
Why does the WebSocket protocol need this mechanism?
A websocket connection is asked by a browser, simply with the code below
new WebSocket("wss://echo.websocket.org")
From the debugger we can see a 101 GET, and by inspecting the request header, we can see this particular entry:
Sec-WebSocket-Key: qcq+klmT4W41IrmG3/fseA==
This is a unique hash, identifying the browser.
On the server side the $client_key hash is received. Only the hash value is kept. The return value looks like this using PHP:
"Sec-WebSocket-Accept: " . base64_encode(sha1( $client_key .
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11",true))
The browser get back the response, (example). This is the sha1 of the sent key concatenated with the 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 websocket unique GUID.
Sec-WebSocket-Accept: r1Km05q03xuNRYy7mxkCRRgbh2M=
The browser is then checking if the hash match his own calculation, done under the hood. If so, the handshake completed, the remote server is actually a real websocket server, and hence the tunnel is created, and kept alive.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
This is a follow up post of my previous question about BASIC auth over HTTPS
Are the path to the resource and query string passed securely to the server if I use HTTPS?
i.e.
URI: http://server/path/to/a/resource?with=a&query=string
Server: server
path: /path/to/a/resource
query string: with=a&query=string
This is a really good explanation of this: http://answers.google.com/answers/threadview/id/758002.html#answer
Summary: only the host and port would be visible unencrypted.
In short, yes. But you shouldn't store sensitive data in URL's since it may be visible in the browsers history and server logfiles. And anyone who looks over your shoulder sees it too.
Yes it is - the entire session is secured and encryped so anything you send, including the query string is unreadable.
You can prove this to yourself, if you wish, by using something like Fiddler to view the http/https traffic you generate when you visit a secure url. Anything you send over HTTPS will not show the querystring, as shown here:
The actual URL I was visiting looked like this:
https://www.halifax-online.co.uk/_mem_bin/formslogin.asp?source=halifaxcouk&simigvis=
As per other answers, you shouldn't pass any sensitive information in the querystring as this may be stored in your webservers log files, so if you were passing a username/password combination anyone who could access your logs would be able to capture that information. This could allow someone to log into your site/application as if they were someone else even if you were making efforts such as storing passwords in your database as salted hashes, rather than plaintext.
HTTPS is simply HTTP tunnelled over an SSL connection. This means that the request, response, headers and content are all within the SSL tunnel and should therefore be encrypted.