I am pretty new to security aspect of application. I have a C++ window service (server) that listens to a particular port for http requests. The http requests can be made via ajax or C# client. Due to some scope change now we have to secure this communication between the clients and custom server written in C++.
Therefore i am looking for options to secure this communication. Can someone help me out with the possible approaches i can take to achieve this.
Thanks
Dpak
Given that you have an existing HTTP server (non-IIS) and you want to implement HTTPS (which is easy to screw up and hard to get right), you have a couple of options:
Rewrite your server as a COM object, and then put together an IIS webservice that calls your COM object to implement the webservice. With this done, you can then configure IIS to provide your webservice via HTTP and HTTPS.
Install a proxy server (Internet Security and Acceleration Server or Apache with mod_proxy) on the same host as your existing server and setup the proxy server to listen via HTTPS and then reverse proxy the requests to your service.
The second option requires little to no changes to your application; the first option is the better long-term architectural move.
Use HTTPS.
A good toolkit for securing your communication channel is OpenSSL.
That said, even with a toolkit, there are plenty of ways to make mistakes when implementing your security layer that can leave your data open to attack. You should consider using an existing https server and having it forward the requests to your server on the loopback channel.
It's reasonably easy to do this using either OpenSSL or Microsoft's SChannel SSPI interface.
How complex it is for you depends on how you've structured your server. If it's a traditional style BSD sockets 'select' type server then it should be fairly straight forward to take the examples from either OpenSSL or SChannel and get something working pretty quickly.
If you're using a more complex server design (async sockets, IOCP, etc) then it's a bit more work as the examples don't tend to show these things. I wrote an article for Windows Developer Magazine back in 2002 which is available here which shows how to use OpenSSL with async sockets and this code can be used to work with overlapped I/O and IOCP based servers if you need to.
Related
Is it possible with Qt to upgrade a HTTP connection that handles the normal HTTP requests to a Websocket with the same connection?
I'm thinking about something like this with Poco libraries, but all done in Qt similar to QtWebApp.
The simple answer is no and that is mostly because of specifics of the server side. And Qt just follows the protocol available and exposed by the server (HTTP/WebSocket) as mostly the client-side development framework and AFAIK won't be able to do the kind of transformation you want of going from HTTP to Websocket that are two different protocols. But of course, theoretically that can be done as long as both protocols able to use IP port 80. But that implies new unique sever and new unique client implementations.
We use both WebSocket and REST in our app. And WebSocket is for triggering the client by the server to do something. Client gets the "poke" from the server and starts normal JSON HTTP-based exchange with the server.
Somewhat relative link: https://softwareengineering.stackexchange.com/questions/276253/mixing-rest-and-websocket-in-the-same-api
What advantages are there between implementing SOAP messages over SSL by modifying the web.xml/ejb-jar.xml VS modifying the WSDL with a WS-Policy?
Our project can acheive its goal of having our clients (ourselves) access the Web Service over a secured connection by adding a transport-guarantee but we're not sure if that is a complete/correct solution.
With SSL, you get a point-to-point encryption between client and service. If the service is not the ultimate receipient of the message, but a proxy that routes this message to another service, you have no encryption between the two services, or you have to configure that also.
WS-Security configured via WS-Policy has the potential to give you end-to-end encryption between the client and the ultimate receipient of the message, because you can encrypt the message body. You do not need to configure SSL for every pair of communicating entities. Every proxy can just route the message on, as defined in the header.
That said, if you do not need end-to-end guarantees, but point-to-point is enough (which is your scenario, as far as I understand), I would say that using SSL is a fair choice.
Another thing to consider is that the WS-Security implementations of client and service need to be able to interoperate. SSL generally is quite mature, but my personal experience is that WS-Security implementations are not. So, if you have different WS-* Stacks for client and server, it might be some hacking and trial-and-error to find a policy configuration that works for both.
I want to connect from webserver via dedicated proxy to the intranet. I am not sure if it matters I want to send and receive XML. It would be great if I could use HTTP.
I know of one open port 78xx which I successfully used with a TCP socket as described in this excellent tutorial
Is it possible? Or does the answer depend on the actual proxy configuration - if it scans for the protocol, and dislikes it it's gonna be blocked!?
And what library would you recommend? I just found pion - Can i link it statically? It's almost not possible to install sth on the web server for me.
EDIT My question is probably two-fold:
First, I have to add, there is an existing communication client+server, but the server is a mixup of the concrete socket and networking implementation and the API to the database, consisting of about 10 commands I find hard to extend. So I ask for a generic lib so I can rewrite that API from scratch.
Second, I need session handling, the webapplication passes the user login data to that client and there is a session-id returned which is used for all further communication - until it expires. That was the reason I asked for HTTP, but meanwhile i realized http itself is stateless.
The answer is.... in progress.- I need to practice more with c++ tcp libs etc.
My post was unfortunately hard too understand, Had some confusion about that all.
I am currently reading on Web Services. There is a SOAP tutorial at http://www.w3schools.com/soap/soap_intro.asp . The following paragraph is from that page:
"Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic."
I don't understand this. Can someone explain it to me, please. Escpecially I want to know, why RPC is a security problem (at lease over HTTP). Knowing why exactly it is a compatibility problem would be nice, too.
The point they're making is that "traditional RPC" sometimes uses unusual low-level network protocols that often get blocked by corporate firewalls. Because SOAP uses HTTP, it's traffic is "indistinguishable" from normal web page views, and so is not caught out by these firewalls.
Not too sure about the security point, I think they're probably implying that HTTP can easily be secured over HTTPS and that proprietary RPC protocols often don't. Of course, this is protocol dependant, not all RPC protocols will be insecure, and many of them can be tunnelled over HTTPS.
Regarding compatibility, the problem is that it's not obvious to make something that uses DCOM talk to something that uses CORBA, for example. One of the aims of SOAP is to provide interoperability, so as to harmonize the way this sort of communication is implemented. (There may still be a few glitches regarding interoperability with SOAP, depending on the tools you use.)
Regarding security, for a long time, policies have been made around using port numbers to distinguish applications: if you want to block a certain service (say NNTP), you block its port at the firewall level. It makes it easy to have a coarse control over which applications may be used. What SOAP over HTTP does is pushing the problem at the layer above. You can no longer distinguish which application or service is used from the port number at the TCP level, instead, you would have to be able to analyse the content of the HTTP message and the SOAP messages to authorize certain applications or services.
SOAP mostly uses HTTP POST to send its messages: that's using HTTP as a transport protocol, whereas HTTP is a transfer protocol, therefore not using HTTP in accordance to the web architecture (SOAP 2 may have attempted to improve the situation). Because almost everyone needs access to the web nowadays, it's almost guaranteed that the HTTP ports won't be blocked. That's effectively using a loop-hole, if no security layer is added on top of this.
This being said, in terms of security, there are advantages in using HTTP for SOAP communication as there is more harmonization in terms of existing HTTP authentication systems for example. What the SOAP/WS-* stack attempts to do is to harmonize the "RPC" communications, independently of the platform. It's not a case of "SOAP is secure" v.s. "DCOM/CORBA isn't", you still have to make use of its security components, e.g. WS-Security, and you may have been able to achieve a reasonable level of security with other systems too.
I asked the question before but didn't phrase it quite right. I'm using RESTful principles to build a secure web-app that uses both transport authentication/encryption and message level security.
The message level security is essentially client-independent (still encrypted though), and hence this allows the individual messages to be cached, or stored on an intermediary server without significant risk of exposing private data.
Transport level security is needed to authenticate both end-points using TLS client-authentication. The situation is analogous to having a central mainframe where messages originate, and caches at each branch where the clients are located. I want the client->cache and cache->mainframe connections to be secured using TLS and the individual X509 Certificates. Hence, the client will know it is talking to a proxy, and the mainframe will know it is talking to the proxy and not directly to the client.
Is there some way of doing this using HTTP standards, and not through some hack?
Essentially, I want the client to try and access the mainframe URI, to know it has to go through the proxy, and use TLS with the proxy (with the proxy having its own certificate), and then for the proxy to proceed to connect to the mainframe (with each having their own certificate) on behalf of the client. The proxy can cache the data the mainframe returns, and use that instead of having to connect to the mainframe each time.
Does anybody know proxy/caching software or a method that will allow this?
Would this get more responses on serverfault.com as it's essentially a server software/config question rather than a programming problem per se?
Basically, it sounds like you want a standard SSL reverse proxy with caching. You could do this without writing any code with Apache + mod_cache, configured as a reverse proxy.
The kicker is the message security. It'd only work if your requests are 100% cacheable based only on path/querystring, and if they were "unique by client" (eg, a client ID in the QS or something). Something tells me that one or both of these are not true. This would be pretty trivial to build in ASP.NET, or by extending mod_cache (basically just standard response caching, bucketed by the client cert thumbprint).