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?
Related
I am using the node-wot browser library and I would like to connect IoT-devices communicating via MQTT and CoAP to the browser. As the browser/ library is not capable of communicating via MQTT or CoAP, are there any implementations of HTTP-CoAP or HTTP-MQTT proxies available which can process thing descriptions?
The idea would be to have a proxy where I could connect my device to, simply by providing a w3c wot thing description. Ideally the proxy would create another thing description which I could use to connect the browser to the proxy via HTTP.
You can check out the shadow-thing project for an existing implementation but it is rather easy to this yourself with node-wot:
Fetch the TD of the Thing you want to proxy and consume it to create a consumed thing.
Take that TD and put it into the produce() method.
Add handlers for all the affordances
In each handler make the appropriate call to the consumed Thing.
Resolve the messages you get via your exposed Thing so that they are returned to your consumer.
For me the requirements are not that clear.
The open source project Eclispe/Californium comes with coap2http cross proxy functionality (and also http2coap). You may try it demo-apps/cf-proxy2
I am currently trying to create a "TOR version" of a service I created, running with TLS. I want to perform mutual authentication of both parties ; client and server.
I thought about using TLS-PSK over TOR, which would gives me the properties I desire, especially eavesdropping prevention.
I wanted to use the socket library and to double wrap a socket instance using first the ssl library then to do the same thing with TOR, but it looks like there is no library existing allowing me to do the second wrapping.
Do you have any idea about existing libraries allowing me to do something like that ?
I am building an application which can have multiple gRPC servers and definitely will have multiple gRPC clients, I wanted to know, how to identify on server side that this is the client I am talking to and only send data to that client. I am using bidirectional streaming RPC and right now the data gets broadcasted to every client and I don't want that. What functions in go gRPC make it possible or how can I implement it?
There are two ways to read this question. One way is to read it as the auth problem as answered before. The second way is how I read it, as a connection/session problem.
When the client connects, the grpc server will invoke a function to implement the call in its own goroutine, and that function will be only talking to the client that initiated that call. So, the struct you registered as your grpc server will be shared among many connections, but each connection will run in its own goroutine, and will only talk to the client that initiated it. That also means you have to make sure the grpc server implementation is thread-safe.
You mentioned data is being broadcasted to every client? There is no broadcast in grpc, are you sure that's what's happening?
This sounds like a common authentication/authorization problem that ultimately won't have much to do with gRPC or Go.
You need a way for a client to indicate who they are. Personally I'm a fan of JWTs. In a standard HTTP request, there are authorization headers that can indicate who is making the request. Similarly, gRPC supports meta data attached to each remote call. In my current work project, every call must have a JWT in the meta data or else I don't process the request. Every call except the login endpoint that is.
I haven't looked into how to get details like a gRPC client's IP address or other information about a client's connection but chances are that anything provided by gRPC's generated code is something potentially faked by the client. When architected correctly, JWTs can offer cryptographic confidence that the client is who they claim to be.
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 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.