I need to connect to a server with SSL in C++Builder XE7. I can find stuff for HTTPS and SMTP but nothing for custom connections. In BCB5 it was a lot easier, I would do it with custom code but now with Android and iOS, things need to be done a little differently as we now need to support these products too.
I've looked at TIdSocketSSL but with the very few examples I could find, it seems to need an owner which ultimate comes from SMTP or HTTPS.
C++Builder ships with Indy, which has a TIdTCPClient component that you can use for implementing custom protocols. There are plenty of examples on Embarcadero's forum, Indy's forum, StackOverflow, and various blogs demonstrating how to send/receive custom data with Indy.
For SSL/TLS, simply assign a TIdSSLIOHandlerSocketOpenSSL component to the TIdTCPClient::IOHandler property before calling Connect(), and configure its properties as needed (certificates, SSL/TLS version(s), etc). When you want to perform the SSL handshake, set the TIdSSLIOHandlerOpenSSL::PassThrough property to false. You can set it before calling Connect() so the handshake is immediate before any data is exchanged (aka implicit SSL/TLS), or you can set it after exchanging unencrypted data first (aka explicit SSL/TLS), depending on your protocol needs.
Related
I want a client/server C++ application that can use TLS for secure communication, including client certificates, and potential to select and validate certificates myself.
I have used Schannel to do this before, but the key InitializeSecurityContext is marked [desktop apps only].
Have Microsoft provided a new equivalent API?
Although in theory I could replace the whole thing (since in the end, I can still have a normal plaintext TCP socket) I would rather stick to OS components if possible.
I'm a bit confused about using OpenSSL in my Delphi webservice in relation to the available ciphers for a HTTPS connection.
Setup:
My webservice runs on a client's server. OpenSSL is installed there. The webservice uses Indy (a TIdHTTPWebBrokerBridge) and the OpenSSL DLLs (with TIdServerIOHandlerSSLOpenSSL) to load the client's certificate
Our Android/iOS apps connect to this webservice over HTTPS
The client has configured a domain and IP that the app users can connect to and reach my webservice. If we test that domain using e.g. the SSLLabs server test we get an overview of the supported ciphers and protocols (SSLLabs even mimics handshakes from devices and browsers and shows what ciphers were negotiated).
Question: Is there anything my webservice (in combination with OpenSSL) has to do/can do to influence the available ciphers for the TLS handshake between app and webservice? Is there anything additional that needs to be setup with OpenSSL?
I thought the answer is 'no', i.e. that it is just the server setup that (in the handshake with the app through Android/iOS) determines which cipher to use from the available server ones. Is this a correct assumption? Or do I miss something?
(As a matter of fact, I am not actually interested in limiting or expanding the available ciphers, but the client insists that something "should be done" in/with the webservice/OpenSSL to have it communicate "safely" with the apps. The SSLLabs test shows that their domain only supports TLS 1.0 and ciphers with the RSA key exchange mechanism, so e.g. no Perfect Forward Secrecy. To me, that looks like something that needs to be fixed anyway).
Notes:
This SO question suggests I may have to do something, but it has no answers.
I posted an earlier somewhat related question, but that has no answers.
This SO post states OpenSSL honors the client's cipher preference, not the server's, during the SSL handshake, which again suggest there are things I can do?
I had some doubts whether this question is in the proper place here (also because Why we are not customer support), but since this may be relevant to more programmers I decided to put it on SO.
You can specify available ciphers via TIdServerIOHandlerSSLOpenSSL.SSLOptions.CipherList (as well as SSL/TLS versions via TIdServerIOHandlerSSLOpenSSL.SSLOptions.SSLVersions).
If you want Perfect Forward Secrecy, you has to create DHParam keys using openssl.exe (fill TIdServerIOHandlerSSLOpenSSL.SSLOptions.DHParamsFile by result file name). If you want not only DHE, but ECDHE ciphers you need to call some additional openssl api, see a Support for Perfect Forward Secrecy in SSL with indy 10 for example.
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
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 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.