[Dillo-dev]https (eg for posting to ps2 bulletin boards)
Every time I read the playstation2-linux lists I realise how very useful dillo will be when it gets just a little further. How's the short/medium term future of https looking?(*) If an official plugin is in the offing then that's probably what we should all wait for. Otherwise, is the patch from 0.7 resurrectable?? Bob (*You need ssl to post to the ps2 bulletin board) -- robert w hall
On Sun, 30 May 2004, robert w hall wrote:
Every time I read the playstation2-linux lists I realise how very useful dillo will be when it gets just a little further.
Please elaborate a bit on this subject.
How's the short/medium term future of https looking?(*) If an official plugin is in the offing then that's probably what we should all wait for.
The short term looks very good, at this time we only need some TLS or SSLlib savvy guys, with some time willing to polish our current prototype. The main problem with the past prototypes and patches is that they don't handle connection caching (nor provided for an easy way to implement that), and the most important, they don't do certificate validation! The current prototype for SSL (using dpi) provides for an easy way of implementing connection caching, and for asking the user (using dillo's API) whether to continue on unverified connections, the SSL part of this verification is not yet done though. As Madis put it:
Most important thing missing from the ssl specific code is certificate verification - it MUST be done in order to have any actual security. In its current form it just gives a way to access SSL sites, but not secure access.
I know people look forward to the day when they can complete their online shopping with dillo, but we must be very careful to provide real security. This is key. Unfortunately I'm not an encryption expert, and we need some help from a savvy guy (the chances of a SSL freshman to make mistakes is very high). I'd love to have a TLS based dpi for https (TLS lib is GPLed and is a requisite to NPTL, so it'll become as ubiquitous as SSL lib). The current prototype is SSLlib based, but is enough to start polishing and extending the code. Some time ago Madis wrote an SSL gateway for Dillo. After some work, I decided to integrate it through the dpi framework (to empower it with dpip and also to avoid some quirks by using the standard way to extend dillo). That is the current prototype. Just in case an SSL/TLS savvy person is reading: the work with the dpi is quite simple, you don't need to know about Dillo's internal working, actually the https dpi is a C program that's independent of Dillo. The dpi just needs to make the secure connection to the remote server (and verify the cerificate), then forward the http stream to dillo, or ask whether to close or proceed when it can't verify. This is done with a simple dpid tag, all the SSL stuff happens inside the dpi.
Otherwise, is the patch from 0.7 resurrectable??
Sure, but not worth. At least the current prototype can POST. Cheers Jorge.-
In article <Pine.LNX.4.58.0406012204150.740@infinity.cl>, Jorge Arellano Cid <jcid@dillo.org> writes
On Sun, 30 May 2004, robert w hall wrote:
Every time I read the playstation2-linux lists I realise how very useful dillo will be when it gets just a little further.
Please elaborate a bit on this subject.
Well it's a lovely browser for that sort of machine (300MHz MIPS R5900 processor, 32MB of RAM), and I usually recommend anyone who is asking on the official site (www.playstation2-linux.com) to go get a copy in preference to, or at least along with, the gargantuan firefox. But it's a bit hard to have to tell a newbie that he won't actually be able to use dillo to post back to the same site he's reading from (needs SSL to post). They usually just go off and use firefox and s*d the disc thrashing! It doesn't need to be a very secure implementation (though I note and respect your reasoning here) - there was a patch available all though the 0.6 and 0.7 series which I think usually got implemented in the pre- compiled dillo downloads at the ps2 site... With the recent dropping in price of the ps2-linux kit, there are quite a few new-starters, who are trying to see what they can use on the net, and so a slightly-extended dillo would (IMHO) be very timely. Bob -- robert w hall
On Tue, 1 Jun 2004, Jorge Arellano Cid wrote:
The current prototype for SSL (using dpi) provides for an easy way of implementing connection caching, and for asking the user (using dillo's API) whether to continue on unverified connections, the SSL part of this verification is not yet done though.
As Madis put it:
Most important thing missing from the ssl specific code is certificate verification - it MUST be done in order to have any actual security. In its current form it just gives a way to access SSL sites, but not secure access.
I know people look forward to the day when they can complete their online shopping with dillo, but we must be very careful to provide real security. This is key.
I hope to look at it (probably in july).
Unfortunately I'm not an encryption expert, and we need some help from a savvy guy (the chances of a SSL freshman to make mistakes is very high).
Yes, it is a hard thing. There were for example a same SSL certification chain handling bug in IE and Konqueror. It would help, when someone would write a library-like code for verifing peers certificate with simple interface. I'd look the existing implementations in Konqueror SSL plugin and Mozilla for reference. For example something similar to this: /** * Check the peer's certificate. * * \param connection current SSL connection * \param result the verifications result * 0 - ok * 1 - we don't know wtf it is, ask confirmation * and tell user, that good answer is NO. * 2 - error, couldn't do the verification * .... * \return message for user */ char* chain_verify(SSL *connection, int *result); /** * User said, that he likes that one... * * \param cert certificate to remember * \return 0 - error (message in openssl error stack), 1 - OK */ int remember_certificate(X509 *cert);
I'd love to have a TLS based dpi for https (TLS lib is GPLed and is a requisite to NPTL, so it'll become as ubiquitous as SSL lib). The current prototype is SSLlib based, but is enough to start polishing and extending the code.
Some time ago Madis wrote an SSL gateway for Dillo. After some work, I decided to integrate it through the dpi framework (to empower it with dpip and also to avoid some quirks by using the standard way to extend dillo). That is the current prototype.
http://www.zone.ee/myzz/dillo/https_dpi/https_dpi.tar.gz But if someone knowledgeable of crypto, SSL and TLS library goes to write the TLS version of it, do it (and tell the list). I do not know the TLS library by myself.
On Wed, 2 Jun 2004, Madis Janson wrote:
On Tue, 1 Jun 2004, Jorge Arellano Cid wrote:
The current prototype for SSL (using dpi) provides for an easy way of implementing connection caching, and for asking the user (using dillo's API) whether to continue on unverified connections, the SSL part of this verification is not yet done though.
As Madis put it:
Most important thing missing from the ssl specific code is certificate verification - it MUST be done in order to have any actual security. In its current form it just gives a way to access SSL sites, but not secure access.
I know people look forward to the day when they can complete their online shopping with dillo, but we must be very careful to provide real security. This is key.
I hope to look at it (probably in july).
Good!
Unfortunately I'm not an encryption expert, and we need some help from a savvy guy (the chances of a SSL freshman to make mistakes is very high).
Yes, it is a hard thing. There were for example a same SSL certification chain handling bug in IE and Konqueror.
It would help, when someone would write a library-like code for verifing peers certificate with simple interface. I'd look the existing implementations in Konqueror SSL plugin and Mozilla for reference.
I read a lot of the GnuTLS manual, and found some interesting facts and functions that could help. Including a function somewhat like what you sketched:
For example something similar to this:
/** * Check the peer's certificate. * * \param connection current SSL connection * \param result the verifications result * 0 - ok * 1 - we don't know wtf it is, ask confirmation * and tell user, that good answer is NO. * 2 - error, couldn't do the verification * .... * \return message for user */ char* chain_verify(SSL *connection, int *result);
/** * User said, that he likes that one... * * \param cert certificate to remember * \return 0 - error (message in openssl error stack), 1 - OK */ int remember_certificate(X509 *cert);
I'd love to have a TLS based dpi for https (TLS lib is GPLed and is a requisite to NPTL, so it'll become as ubiquitous as SSL lib). The current prototype is SSLlib based, but is enough to start polishing and extending the code.
Some time ago Madis wrote an SSL gateway for Dillo. After some work, I decided to integrate it through the dpi framework (to empower it with dpip and also to avoid some quirks by using the standard way to extend dillo). That is the current prototype.
Here follos an abridgment of interesting information inside the GnuTLS manual: <q> http://www.gnu.org/software/gnutls/manual/gnutls/gnutls.html -- Description: Technically GnuTLS is a portable ANSI C based library which implements the TLS 1.0/1.1 and SSL 3.0 protocols, accompanied with the required framework for authentication and public key infrastructure. The library is available under the GNU Lesser GPL license1.2. Important features of the GnuTLS library include: * Support for TLS 1.0, TLS 1.1 and SSL 3.0 protocols. * Support for both X.509 and OpenPGP certificates. * Support for handling and verification of certificates. * Support for SRP for TLS authentication. * Support for TLS Extension mechanism. * Support for TLS Compression Methods. Additionally GnuTLS provides a limited emulation API for the widely used OpenSSL1.3 library, to ease integration with existing applications. --- Verifying peer's certificate A TLS session is not secure just after the handshake procedure has finished. It must be considered secure, only after the peer's certificate and identity have been verified. That is, you have to verify the signature in peer's certificate, the hostname in the certificate, and expiration dates. Just after this step you should treat the connection as being a secure one. The following function is a simple example on how to verify a single certificate. Real world programs should be able to handle certificate chains as well. --- /* This function will try to verify the peer's certificate, and * also check if the hostname matches, and the activation, expiration dates. */ void verify_certificate(gnutls_session session, const char* hostname) [...] --- Resuming Sessions: The gnutls_handshake function, is expensive since a lot of calculations are performed. In order to support many fast connections to the same server a client may use session resuming. Session resuming is a feature of the TLS protocol which allows a client to connect to a server, after a successful handshake, without the expensive calculations. This is achieved by using the previously established keys. GnuTLS supports this feature, and the example resume client illustrates a typical use of it. --- http://msmtp.sourceforge.net/ (GPL) Version 1.0.0: - correctly handle certificate chains in tls.c GnuTLS code --- Interview (Nikos Mavroyanopoulos): http://www.gnu-friends.org/story/2003/12/17/14525/717 </q> Some remarks: The msmtp project is interesting because is GPLed, and handles certificate chains, so it can be reused. The "Resuming Sessions" feature is also interesting because it could initially account for what we've been calling "connection caching". (i.e. instead of keeping an SSL socket alive to communicate with the server, a new session can be requested, and GnuTLS' "resuming sessions" does the rest). The documentation is clear and comes with several examples. Please give it a look Madis. Cheers Jorge.-
participants (3)
-
Jorge Arellano Cid -
Madis Janson -
robert w hall