I am currently adding SSPI Schannel API support to libcurl in order to make it possible to use SSL enabled protocols on Windows without any external dependency, such as OpenSSL.
I already have a working SSL/TLS implementation, but I have a very specific question regarding the re-use of credential handles returned by the function AcquireCredentialsHandle.
Is it correct and possible to re-use SSL/TLS sessions by instead of creating a new handle, re-using an existing one and passing it to InitializeSecurityContext multiple times?
My work on the Schannel module for libcurl can be found here, and the experimental version that tries to re-use can be found here.
I would appreciate any kind of hint or feedback on this one. So, can credential handles be re-used in such a way? And is it correct?
Thanks in advance!
I found the answer to my question and record it here for others:
It has been asked before and a first answer can be found here.
The following information can be found on this MSDN page:
Your application obtains credentials by calling the AcquireCredentialsHandle function, which returns a handle to the requested credentials. Because credentials handles are used to store configuration information, the same handle cannot be used for both client-side and server-side operations. This means that applications that support both client and server connections must obtain a minimum of two credentials handles.
Therefore it can be assumed safe to re-use the same credential handle for multiple connections. And I verified that it indeed makes Schannel re-use the SSL/TLS session. This has been tested on Windows 7 Professional SP1.
Related
general questions about the using of *fail_if_no_peer_cert *and *fail_if_no_peer_cert *params in *rabbitmq_management *on windows
if a client calls management API through https, the requests are secured by the certificate which is installed on the server and trusted on the client. actually, it means, this certificate shouldn't be rabbitmq compatible, it can be just http-certificate... is it correct?
in case i want to validate clients as well, i must have these params verify and true? what is the best practice? because i see these params explained in AMPQ settings and never in management
actually my motivation for this questions is just to understand if i need to deal with this issue at all. because setting *fail_if_no_peer_cert *as true makes a lot of things much more complicated. foe example you just can simply open management api plugin in browser, you need deal with client certificate.
I am experimenting with Google RPC and managed to establish an encrypted connection. Now I would like to perform NTLM authentication on server. I know that I should use a pair of functions InitializeSecurityContext and AcceptSecurityContext for that.
I was intending to do it by myself, but then I found traces of these functions in Indy components, namely in IdAuthenticationSSPI.pas and IdSSPI.pas. After unsuccessful attempts to figure out what and how could I use for my task from Indy library, I started to look for examples in Internet, but all these examples work with TIdHTTP component.
Could I really use SSPI separately from Indy?
I'm working on a PoC of a system where a mobile app client needs to be connected on a server with communications going both ways : either for updating the server or being updated by it. There is no client-to-client communications for the moment.
The client logs in the server via an HTTPS/POST method and gets back a token if the credentials are OK. This token is to be used by any further communication in order to authenticate the user. The reason why I'm using HTTPS for logging in is that there also is a web interface for other purposes.
I could not find a tutorial or documentation that explains how to implement this use case with channels based on websocket transport. All I found so far are either partial and focus on some specific aspects (eg authentication, setting SSL/TLS, etc) and assume the reader already knows the rest or are the over simplified implementations of the chat app. I'm sure I'm not looking at the right place...
My questions are:
What would be the list of callback to implement this use case on
either side
On the server: how does a process send notifications to the
client
NB: I'm using Elixir 1.5.1 and Phoenix 1.3
From the Phoenix guide:
Each Channel will implement one or more clauses of each of these four callback functions — join/3, terminate/2, handle_in/3, and handle_out/3.
The page I linked contains also an MCVE of sockets running on Phoenix. In the bottom there are examples of how the server-client communication is done.
The only thing to apply this to your use-case would be to use one of authentication libraries (e.g. Überauth that comes with great examples) to handle token on each subsequent connection request.
I am recentlly finding a solution of Web Security, As far as i known the HTTPS will bring more security web, but i found another Security solution of JOSE(JWT&JWE) so i want to known, i use it in the future, can i just use HTTP only but without HTTPS ?
Kris.
Thanks
Your question is legit to me and I am sorry to see that you received downvotes.
As far as i known the HTTPS will bring more security web, but i found another Security solution of JOSE(JWT&JWE)
I think there is a confusion between the both technologies.
JWE is just a format that represents content using JSON based data structures and that provides integrity protection and encryption whereas HTTPS is a secured layer for the HTTP communication protocol.
JWE is not a replacement to the HTTPS protocol.
The use of one technology, the other one or both of them only depends on your application context. HTTPS may not be absolutely necessary in some contexts and the secured communication provided by other means.
You mentioned that you want to find a solution for a security application. A secured connection should be always used in that context.
You absolutely need HTTPS even if you are using JWTs and JWEs. HTTPS allows your client to verify that they are talking to the server they are expecting to talk to. It also protects the content of the communication, including the JWT/JWE tokens that you are using. Without HTTPS, anybody who can listen to the communication between your client and your server can impersonate your clients.
JWTs in particular can carry information about your user. You may not need to forward it to the authorization server that granted the token (if you are using an asymmetric signing key) and still have enough information about the identity and permissions of your user to grant or deny them access to the resources that you are protecting.
I have a https connection from Client to Server and a malware in client. The malware modifies the message and compromises its integrity. I am using a proxy to check the Integrity of the message after the malware has changed the message and before sending it over the internet to the server.
Now, How can I check the Integrity of the message (Sure that it has not been modified by any Man in the Middle) for the second half of my communication channel(Which is from Client to the Server over the internet).
I see few conventional approaches of CRC or Checksum will help. But I am looking for some non traditional or upcoming approaches. I am new to this area and want to take expert advise about the direction I need to search for answer to my question.
Any pointers would be of great help.
Thanks,
As I mentioned in your other question, if you have an https session, you can't do this.
If you could do it, it's possible your proxy could be the "man-in-the-middle", which is exactly what SSL is designed to prevent.
Also, it's not clear how you expect the malware on the client side is changing the message - your software can always validate the message before it is sent via SSL, and after it's sent, the only thing that should be able to decode it is the server.
I strongly recommend spending some time learning about specific well known client server security patterns rather than trying to invent your own (or trying to hack apart SSL). A great starting point would be just picking through some questions on http://security.stackexchange.com. (A personal favorite there is this question about how do to password security). There are likely some questions/links you can follow through there to learn more about client-server security (and eventually understand why I'm confused about what it is you're trying to do).
If you are required to make up your own for some reason, a possible (but still hackable with enough determination) way of doing validation is to include a checksum/hashcode based on all the values, and make sure the same checksum can be generated server side from the values. You don't need a "middle" to somehow crack the SSL to do this though - just do the validation on the server side.