I've been asked to look into how we can add SSL support to a piece of client software that communicates over HTTP. We deploy on our clients' systems - so, very heterogenous. Currently, we don't even use LWP::UserAgent or something, we do HTTP ourselves. While that works, doing it for crypto is pushing it (I thought briefly about a pure-perl SSL library, but I don't think one exists, it'd be slow as all get-out, and having us implement crypto is a Very Bad Idea).
I may not be cross-compiling microperl for Nintendo DS, but I don't think CPAN is going to help me much here. Some of the systems don't have OpenSSL, so we'll need them to install it. But some won't be able to do that easily. So, we could ship OpenSSL code ourselves (Alien::OpenSSL?). But some machines won't have compilers. Well, we could cross-compile for some of those machines. But some belong in a museum rather than production, so we won't have a machine to compile with, and we won't be able to cross-compile for everything.
My thinking right now is that where OpenSSL is available, we can require IO::Socket::SSL. Where OpenSSL isn't available, we can have clients provide it, or we can ship it ourselves, and get IO::Socket::SSL. For others, we can compile and ship binaries. For the last category, the problem might be intractable. For systems with no compiler, and where we can't cross-compile, we might have to add a node in the remote network to forward-proxy over SSL.
This is a very unfortunate situation, clearly, but I have a hard time imagining that nobody has had to do this before. I'd love to hear any suggestions, pitfalls you foresee, or potential solutions you've heard about.
In reply to SSL support without OpenSSL or a compiler by doherty
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |