Do-It-Yourself SSL Proxying?

By Jon Udell

February 14, 2001

(SSL Proxying :  Page 3 of 3 )

In this Article

SSL Proxying A Window Into Encrypted Client/Server Conversations Do-It-Yourself SSL Proxying?

A basic proxy server is a very easy thing in Perl. Here's one based on Perl's HTTP::Daemon and LWP modules:

#! /usr/bin/perl -w
use strict;

use HTTP::Daemon;
use LWP;

my $d = new HTTP::Daemon LocalPort=>$ARGV[0];
print "Please contact me at: url, ">\n";

my $ua = new LWP::UserAgent;

while ( my $c = $d->accept )
{
while ( my $request = $c->get_request )
{

# have your way with $request here...

my $response = $ua->request($request);

# have your way with $response here...

$c->send_response($response);
}
$c->close;
undef($c);
};

If you run this at 8080, and point your HTTP proxy setting at it, you've got a tiny proxy server. It does exactly nothing, but is in a position to do all sorts of magic by altering either the request it receives from the browser, or the response it receives from the destination server, or both.

What happens if you point your secure proxy setting at this same Perl-based proxy? It won't work, not surprisingly, but it does receive an initial cleartext request. If you print its contents (using Perl's invaluable Data::Dumper module) you'll see that it is neither a GET nor a POST, but rather, a CONNECT.

In a newsgroup discussion, Peter Hess pointed to a couple of documents that describe the CONNECT method. Notes RFC 2616 (the HTTP 1.1 spec):

9.9 CONNECT

This specification reserves the method name
CONNECT for use with a proxy that can 
dynamically switch to being a tunnel 
(e.g. SSL tunneling [44]).

According to Netscape's Previous page Page 3 of 3 

BYTE.com > Tangled in the Threads > 2001 > February