Does a specific reason exist why I should not always use a TIdSSLIOHandlerSocketOpenSSL instance as IOHandler to my TIdHTTP instance or should I always check was I requested to get a https or a http site?
Andrea Raimondi Agreed, but so far as I know Indy can't work with HTTPS (via the TIdHTTP component) without shipping third-party DLLs for the SSL support. That's the result of some research at the time, anyway. I'd be very happy to be contradicted, since I'd much prefer to use HTTPS all the time.
As far as I know, you are correct. And, quite frankly, I'd rather use OpenSSL instead of a custom implementation anyway. The problem - if you will - with OpenSSL DLLs is the just the same one as every other widespread Open Source DLL: it is not immune to attacks because you could - in theory - compile a malicious version and replace the legit one. Even with that concern, I would still prefer the OpenSSL DLL to anything custom.
David Millington in my view. unless you have a specific reason to go with HTTP - you should always go with HTTPS.
ReplyDeleteA
Andrea Raimondi Agreed, but so far as I know Indy can't work with HTTPS (via the TIdHTTP component) without shipping third-party DLLs for the SSL support. That's the result of some research at the time, anyway. I'd be very happy to be contradicted, since I'd much prefer to use HTTPS all the time.
ReplyDeleteAs far as I know, you are correct. And, quite frankly, I'd rather use OpenSSL instead of a custom implementation anyway. The problem - if you will - with OpenSSL DLLs is the just the same one as every other widespread Open Source DLL: it is not immune to attacks because you could - in theory - compile a malicious version and replace the legit one. Even with that concern, I would still prefer the OpenSSL DLL to anything custom.
ReplyDeleteA