It really is disappointing that the Javadoc for SSLSocketFactory is so
vague. As we've discussed, createSocket() has a parameter for the
already-connected socket to be wrapped, then for some reason it also has
parameters for host and port. I would think the first thing anyone looking
at these parameters would want to know is why the host and port are being
supplied again, given that the wrapping operation is not meant to change the
already-established connection. But the documentation is not very clear
(question marks are mine):
Returns a socket layered over an existing socket connected to the named
host, at the given port. This constructor [??] can be used when tunneling
SSL through a proxy or when negotiating the use of SSL over an existing
socket. The host and port refer to the logical peer destination [??]. This
socket is configured using the socket options established for this factory.
The proxy reference partially makes sense because, for example, when you are
connecting through an HTTP proxy you first connect directly to the proxy
using a plain socket connection because you do NOT want to perform the SSL
handshake with the proxy. Once the proxy bridges you to the final
destination server, you can use createSocket() to layer an SSL socket over
the already-connected socket and initiate the SSL handshake. But you inform
the proxy of the host and port of the final destination server through
conventions of the HTTP protocol, not through the host and port provided to
the Java createSocket() API.
If anyone out there understands how the host and port parameters are used
when wrapping an already-connected socket, please share. Otherwise I think
they're ignored.
Clint Foster
Axway
On 3/9/07 8:59 AM, "Niklas Gustavsson" <[EMAIL PROTECTED]> wrote:
> Clinton Foster wrote:
>> DefaultSsl.createSocket(String, Socket, boolean) calls
>> SSLSocketFactory.createSocket(sock, host, port, true) to layer an SSL socket
>> around an already-connected socket. I notice the code is passing in the
>> remote host for the host parameter, and the *local* port for the port
>> parameter. Sun's Javadoc isn't much help describing what those parameters
>> are for. They don't make a lot of sense, given that the socket being wrapped
>> must be connected already. I decompiled some of Sun's code, and it looks as
>> if the port might not be used.
>>
>> The code works, so I'm not complaining about that. I just wondered about the
>> discrepancy between local and remote in those two parameters.
>
> I had a look at the code and read some in Java Network Programming and
> got to say that I don't think we're doing the correct thing in using the
> local port. The SSL socket is being wrapped by the cleartext one and is
> normally used with proxies. The host and port should be those of the
> final destination. In our case that's the same as the original one.
>
> Funny that it seems to work anyhow.
>
> What do you all think, is the correct thing to change this behavior?
>
> /niklas
>
