- From: <jose.kahan@w3.org>
- Date: Wed, 10 Mar 1999 00:53:01 +0100 (MET)
- To: frystyk@w3.org (Henrik Frystyk Nielsen)
- Cc: Jim_Ravan@avid.com, www-lib@w3.org
In our previous episode, Henrik Frystyk Nielsen said: > > yes, it come up regularly - I have the feeling that it may be hooked into > libwww like this: > > HTTransport_add("secure_tcp", HT_TP_SINGLE, HTSSLReader_new, HTSSLWriter_new); > HTProtocol_add("shttp", "secure_tcp", SSL_PORT, NO, HTLoadHTTP, NULL); > > But I don't know SSLeay > > http://psych.psy.uq.oz.au/~ftp/Crypto/ > > and how easily it would fit with the stream model, though. > Other pointers are the lynx/ssl and Mosaic/ssl ports. Both of those browsers are based SSLEay and on an old customized libwww. Other sample applications exist too. Going from SSLeay to openssl is no problem. I think that in order to adapt SSL into libwww, you'd need to have another network interface, similar to what happens when you want SOCKS support. This interface is for opening up the SSL connections. There are other functions needed to load certificates, verify certificates and so on. Perhaps, the biggest problem is not interfacing the SSL protocol, but the certificate handling on the client side. Should this be in charge of the application or of libwww? More info on SSL, including it's APIs, can be found at: http://www.columbia.edu/~ariel/ssleay/ http://www.openssl.org/ -Jose
Received on Tuesday, 9 March 1999 18:53:08 UTC