How can I request a key update on a TLS v1.3 connection implemented with Win32's SChannel?
In other words, what is the Win32 function that provides similar functionality as SSL_key_update() in OpenSSL?
I did not find any useful information in the Win32 documentation. It seems to suggest that InitializeSecurityContext() (client side) or AcceptSecurityContext() (server side) may provide this functionality, but when I call this with the current security context as suggested in Renegotiating an Schannel Connection, I get SEC_E_OK but no data is returned that I could send to the other side.
And I see no flag/parameter where I could specify the update type, as in SSL_key_update.
NO. If providing the same phCredential as for the initial handshake, What do you want to update?
As Renegotiating an Schannel Connection you attached said,
Update credentials if applicable and/or context attributes.
EncryptMessage the generated PSecBufferDesc pOutput.
Send the Encrypted data to the other side.
the other side DecryptMessage which return SEC_I_RENEGOTIATE the data.
the other side return to the negotiation loop and call AcceptSecurityContext (Schannel) or InitializeSecurityContext (Schannel), pass SECBUFFER_EXTRA returned from DecryptMessage()
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.
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.
For DELETE APIs, if we hit the API with invalid data, the API responds with proper error message. If we use the same HTTP connection object to hit another API, the request fails.
This issue is not seen for Create or Update APIs. Also if the Delete request is sent with valid data, then using the same HTTP connection object for next request works fine.
Please note that this behavior has implications for connection pooling in client applications, and we were just wondering if its known issue and if there is any available workaround.
I'm trying to use websockify to allow javascript executed in a browser to talk to my hand-written server. When using the latest versions of Chrome and Firefox, I get the following error message from websockify:
Client must support 'binary' or 'base64' protocol
After looking at the code, I've determined that websockify delivers this message and closes the socket whenever both of these protocols fail to appear under the Sec-Websocket-Protocol header received from the client. When I look at the raw data transmitted by Chrome it doesn't even send this header. Is this a problem with Chrome or websockify, or am I failing to provide some information when opening the websocket in my javascript? Or is there some other explanation?
You need to provide the protocol list as part of the object constructor:
var ws = new WebSocket(uri, ['binary', 'base64']);
If you use the websock.js library included with websockify then it will handle this for you. However, note that websock.js does not provide the standard WebSocket API but rather a streaming oriented API. Even if you use a raw WebSocket connection to websockify, note that you will still need to do message reconstruction because normal TCP does not have a concept of messages so the messages chunking from onmessage will be essentially "arbitrary".
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