Hi there, SSL support is one of the biggest lacks in dillo for me. To that end, I'm thinking of adding it in. Without knowing the dillo codebase, I see two obvious options: 1) Add a src/IO/https.c file based on src/IO/http.c 2) Move http.c to using openssl's BIO's which can support either encrypted or clear traffic, as well as filters. 1 seems much more straightforward and will result in quicker https support, but will cause there to be a whole hell of a lot of code duplication between http.c & https.c. 2 seems like the more "moral" choice and will make dillo better, at the cost of making openssl necessary for dillo builds. Is anyone currently working on ssl support in dillo? Are you using either of the above two options? If the answer to the first question is negative, do people have feelings about code duplication vs. reliance on openssl? (of course, there's a third option of #ifdef'ing the hell out of http.c, adding BIO support that can be compiled out leaving the current plain socket-based code, but that would probably be more of a nightmare to maintain than 1) above). Cheers, -- Ami Fischman usenet@fischman.org
On Thu, 13 Mar 2003, Ami Fischman wrote:
Hi there,
SSL support is one of the biggest lacks in dillo for me. To that end, I'm thinking of adding it in. Without knowing the dillo codebase, I see two obvious options: 1) Add a src/IO/https.c file based on src/IO/http.c 2) Move http.c to using openssl's BIO's which can support either encrypted or clear traffic, as well as filters.
Imho it should be a plugin or something alike to avoid bloating dillo with ssl specific code. Current dpi does not support sending raw http to dillo, so maybe simplest solution would be to create pseudo-proxy for https, which sends https queries in unencrypted form to unix socket sitting in ~/.dillo/. Local proxy would then do the actual encryption (some authentication may be required to ensure that both dillo and proxy are actually runned by same user). -- mzz
SSL support is one of the biggest lacks in dillo for me. To that end, I'm thinking of adding it in. Without knowing the dillo codebase, I see two obvious options: 1) Add a src/IO/https.c file based on src/IO/http.c 2) Move http.c to using openssl's BIO's which can support either encrypted or clear traffic, as well as filters. I think the dpi is, in favor of design, the best solution. I am no
Thu, 13 Mar 2003 15:51:09 -0800: Ami Fischman <usenet@fischman.org> programmer, so don't count that much on me. But i have another idea. What about implementing every protocol as dpi? currently the dpi looks, for me as simple user: dpi:/bm/ but why not implementing it as bm://, so http:// would call the http-dpi, ftp:// would call the ftp-dpi, ... This would create a complete module-based client and dillo can be focused on displaying. http:// could be not much more than a wrapped wget, or i am wrong and this whole scheme is impossible? -- Andreas Zwinkau (andi.dasstellenwirinsinternet.de)
Is anyone currently working on ssl support in dillo?
To shed some light on this topic, I have searched the OLD mailing list archive since I did remember quite a bit. Here are some threads : http://sourceforge.net/mailarchive/message.php?msg_id=1975637 http://sourceforge.net/mailarchive/message.php?msg_id=1388644 note the last paragraph !, and follow the link to http://www.geocrawler.com/archives/3/702/2002/1/0/7681591/ Also, note Jonathan Springers work : http://sourceforge.net/mailarchive/message.php?msg_id=1601722 and its continuation at http://sourceforge.net/mailarchive/message.php?msg_id=1610063 BTW, the old archives should be searched from here : http://sourceforge.net/mail/?group_id=603 Could a webmaster change the link to "Old Archives" on http://dillo.auriga.wearlab.de/MList.html ? Finally, note Jorge's very recent mail in which he lists some priorities : http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-March/000229.html Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
Thanks for the great summary. It looks to me like Jonathan Springer already implemented the BIO approach for 0.6.5. The fact that it isn't integrated in 0.7 discourages me from re-writing it for 0.7. Since implementing https as a pluging will require a change to the core dillo code (AFAIK only dpi:/ URL's get handed to plugins), it would be nice to get confirmation from the authors that this is OK (would be a candidate for merging in) before spending the time. Jorge? Cheers, -- Ami Fischman usenet@fischman.org
participants (4)
-
Ami Fischman -
andi -
Andreas Schweitzer -
madis