Board index » delphi » Wrapping Inet to get HTTPS support with Indy?

Wrapping Inet to get HTTPS support with Indy?


2007-01-27 04:49:49 AM
delphi239
Hi,
Am I correct in assuming that currently getting
Indy to work with HTTPS requires external modules?
(+ some legal mumbo jumbo about export countries?)
I was just wondering whether a non-cross-platform
solution could be to simply wrap Inet? I realize
this would require some work to get redirects etc.
working... But still...?
best regards
Thomas Shulz
 
 

Re:Wrapping Inet to get HTTPS support with Indy?

"dk_sz" <XXXX@XXXXX.COM>writes
Quote
Am I correct in assuming that currently getting
Indy to work with HTTPS requires external modules?
It requires the OpenSSL library. The latest version of Indy 10 uses
the official DLLs from www.openssl.org. Indy 9, and older
builds of Indy 10, used custom-built DLLs instead, which are linked to
on the Indy website.
Everything else is built into Indy.
Quote
I was just wondering whether a non-cross-platform solution
could be to simply wrap Inet?
Indy's SSL is generic enough to work with any connection. WinInet is
not quite so generic. Also, by using the socket API directly, Indy
provides functionality that WinInet doesn't. Also, because Indy is
cross-platform, any wrapper interface around WinInet would have to be
generic enough to allow for altenative implementations in other
platforms.
Quote
I realize this would require some work to get redirects etc.
working... But still...?
It would require a major re-write of Indy in general in order to
support what you are suggesting. Not just for TIdHTTP but throughout
all of Indy's conection-based components. There is no incentive for
Indy to do that over using the socket API directly like it currently
does.
Gambit
 

Re:Wrapping Inet to get HTTPS support with Indy?

Quote
It requires the OpenSSL library. The latest version of Indy 10 uses
the official DLLs from www.openssl.org. Indy 9, and older
Yeah OK. Problem just is it puts the responsiblity on
me with regards to encryption technology. I suspect that
is the same reason you opted for an external solution.
If there was some way to use an OS component,
one would not need to worry about it at all AFAIK.
Quote
provides functionality that WinInet doesn't. Also, because Indy is
cross-platform, any wrapper interface around WinInet would have to be
I have not studied the architecture of Indy to have any
formed meaning about this. But if it had been possible to
"plug-in" (e.g. uses clause or whatever) a Windows only
SSL solution, that could probably still make many happy :-)
best regards
Thomas Schulz
 

Re:Wrapping Inet to get HTTPS support with Indy?

"dk_sz" <XXXX@XXXXX.COM>writes
Quote
Yeah OK. Problem just is it puts the responsiblity on
me with regards to encryption technology.
So what? OpenSSL is publically available. Have your installer (or
the user) download it when needed. If you want to ship it with your
application, just be sure to host the files on a non-US server (I'm no
lawyer, but that should protect you from US export laws on
encryption).
Quote
I have not studied the architecture of Indy to have any
formed meaning about this. But if it had been possible to
"plug-in" (e.g. uses clause or whatever) a Windows only
SSL solution, that could probably still make many happy :-)
It already can be. Any class derived from TIdSSLIOHandlerSocketBase
can be used. TIdSSLIOHandlerSocketOpenSSL happens to be Indy's own
derived class. There are other third-party classes available, such as
StreamSec (www.streamsec.com). So there is nothing stopping
you from writing your own, as long as it fits the interface.
 

Re:Wrapping Inet to get HTTPS support with Indy?

Hi
Quote
So what? OpenSSL is publically available. Have your installer (or
the user) download it when needed. If you want to ship it with your
application, just be sure to host the files on a non-US server (I'm no
Well, it is for a shareware application... And
well... Let us just say that I have learnt to try
keep things as simple / streamlined as possible :-)
Quote
It already can be. Any class derived from TIdSSLIOHandlerSocketBase
can be used. TIdSSLIOHandlerSocketOpenSSL happens to be Indy's own
Thanks for the pointer! If at all feasible, I will probably
pick this solution over handling legal stuff and *grief*
documentation writing :)
best regards
Thomas Schulz
 

Re:Wrapping Inet to get HTTPS support with Indy?

Quote
So what? OpenSSL is publically available. Have your installer (or
the user) download it when needed. If you want to ship it with your
application, just be sure to host the files on a non-US server (I'm no
lawyer, but that should protect you from US export laws on
encryption).
No, hosting on a non-US server will not necessarily protect you from US
export laws if you are an American citizen or an American company doing
business outside of the US.
While I am not a lawyer either, even providing the "hooks" in your
application to provide encryption can get you into trouble if you are
not careful.
Before you export a cryptographic application from the US be sure that
you are compliance with the law. Consult with a lawyer familiar with
the ITAR (or newer legislation) to be safe.
 

Re:Wrapping Inet to get HTTPS support with Indy?

Quote
Before you export a cryptographic application from the US be sure that
you are compliance with the law. Consult with a lawyer familiar with
the ITAR (or newer legislation) to be safe.
I am not from the US so that probably provides some safety.
Anyways, I think using the builtin OS support should be OK.
Afterall, the OS only supports it then legal...? It would be
very hard to punish for using builtin functionality in Windows
when it comes to such a basic thing as webcrawling :-)
Then agin, IANAL, sometimes laws are crazy... :-(
When I get time I will still research if WinInet can be used.
I have managed to do this somewhat (wrapping atop on Indy
and then switch if https), but it would be nicer if I could use Indy.
(Would be nice to have redirects, headers etc. in same code)
best regards
Thomas
 

Re:Wrapping Inet to get HTTPS support with Indy?

Depending upon where you live, the export laws regarding encryption are
different. In Europe, there is the "The Wassenaar Agreement". In the
US, the ITAR - If you are in the US (but a non-US citizen) you are still
subject to the ITAR. Check your laws carefully.
Typically, when a company exports an OS, they have to meet export
requirements. that is why Windows ships with 40bit encryption rather
than 128bit and the 128bit High Encryption pack was made available to US
citizens. You can use that functionality in your application. However,
if you export an application that utilizes this functionality, you need
to be in compliance with your export (and in some cases, import laws).
Indy and other open source projects have gotten around this by not
including the OpenSSL libraries with their source. If you want SSL/TLS
functionality, YOU need to obtain the libraries (they do give you the
links) and it is YOU that needs to know your local laws when doing so.
Scary stuff whenever you decide to export an application that includes
high level encryption, eh? that is one of the reasons I pretty much
stopped working in this field except for software that is for use in the
US (the company I work for offers software for public safety).
So, to sum it up, be safe - check your laws before selling your software
outside of your own country.
Charles
dk_sz writes:
Quote
>Before you export a cryptographic application from the US be sure that
>you are compliance with the law. Consult with a lawyer familiar with
>the ITAR (or newer legislation) to be safe.

I am not from the US so that probably provides some safety.

Anyways, I think using the builtin OS support should be OK.
Afterall, the OS only supports it then legal...? It would be
very hard to punish for using builtin functionality in Windows
when it comes to such a basic thing as webcrawling :-)

Then agin, IANAL, sometimes laws are crazy... :-(


When I get time I will still research if WinInet can be used.
I have managed to do this somewhat (wrapping atop on Indy
and then switch if https), but it would be nicer if I could use Indy.
(Would be nice to have redirects, headers etc. in same code)


best regards
Thomas


 

Re:Wrapping Inet to get HTTPS support with Indy?

Quote
requirements. that is why Windows ships with 40bit encryption rather
than 128bit and the 128bit High Encryption pack was made available to US
That was how it was for Win2K as well.
(i.e. a separate disk if I recall correctly)
However, Windows XP / DK had 128 builtin I believe.
Quote
different. In Europe, there is the "The Wassenaar Agreement". In the
US, the ITAR - If you are in the US (but a non-US citizen) you are still
subject to the ITAR. Check your laws carefully.
Thanks for the information / keywords.
Quote
Scary stuff whenever you decide to export an application that includes
high level encryption, eh? that is one of the reasons I pretty much
But by using the OS / WinInet you are not exporting any
code at all. You use the same routines the OS supplies to IE.
You just select and pass a https instead of http in parameters.
If above is illegal, so is using TWebBrowser it would seem? :-)
best regards
Thomas Schulz