BYTE.com > Tangled in the Threads > 2001 > February
What About Secure Sites?
By Jon Udell
February 8, 2001
(Website API Discovery
: Page 2 of 3 )
In fact, you can't always just telnet to a site, or do the equivalent using script-language HTTP modules.
When the site in question is secure, things get a lot more complicated. Or rather, they used to. Now that the RSA patent has expired, they're getting simple again, thankfully. You can, for example, use a marvelous open source tool called stunnel to turn the OpenSSL (formerly SSLeay) libraries into a general-purpose encryptor/decryptor that will let you telnet (or Perl, or Python) a secure site:
stunnel -d localhost:443 -c -r some.secure.site:443
telnet localhost 443
GET /
The "-d" tells stunnel to listen on the local port 443 (which could be any port, including a high-numbered one if you're on a Unix box without root and can't access the lower-numbered ports). The "-c" says "be an SSL client" with respect to the remote host specified by "-r."
This is a terrific enabler. Unlike ssh tunneling, it doesn't depend on a cooperating sshd on the far end. But wait! There's more! Watch this:
stunnel -d localhost:443 localhost:80
Pretend that the service running at localhost:80 is plaintext, but you want to secure it. Maybe it's a homegrown tool, maybe it's Zope, whatever. From the outside looking in, port 443 is now a secure HTTPS service, though under the covers it only relays requests, decrypted, to an ordinary and unmodified HTTP service. The stunnel distribution comes with a default server certificate which, of course, isn't signed by VeriSign, so has to be accepted by the user.
And I wouldn't recommend this approach for heavily trafficked sites. But these limitations are quite acceptable in a great many situations where you need to deploy some service for a small but distributed team, and do it securely.
BYTE.com > Tangled in the Threads > 2001 > February
|
