On Sat, 2003-06-07 at 21:51, Madis Janson wrote:
On Fri, 6 Jun 2003, Jorge Arellano Cid wrote:
The "http to https proxy" is what I call dpi!
I'm working very hard with Ferdi extending the dpi1 design with a general plugin manager. We have working code and it had gone great on tests. I hope to commit the first version in a week or so.
Great!
This will ease the process of understanding and developing a dpi. I hoped all the concepts and internal working to be clear from the dpi1 spec and the bookmarks server code, but it is certainly very complex to understand it fully (inside and outside of dillo and inside the dpi and within the CCC for dpi).
It would be useful, if you could put some of the basic dpi server functionality into a simple library (so dpi tag parsing does not have to be reimplemented in every dpi server written in C).
Now, as I'm not an HTTPS expert, I don't know what interactions will be required to support https fully. That is what data exchanges/questions/ are required for each operation.
For instance, when the server's certificate can't be verified (by the https dpi in this case), the user must be asked whether to accept it under this doubt. This will traduce into a dpi command sent to dillo, something like:
<dpi cmd='question' srv='https' text='Accept unverified connection from this server?' options='YES|NO'>
Then dillo will make the window, ask the user, and send the answer back:
<dpi cmd='answer' srv='https' answer='YES'>
...and the https dpi can resume.
It would be nice, if some certificate fields (issuer, dates) and certificate MD5/SHA1 hashes would be also shown to the user. This allows user to verify the certificate hash in a rare case, when (s)he has got the hash previously using some trusted channel (printed to paper for example).
Appart from this one, what else is required? That I don't know in detail. <-- (this is a question!)
On the connection side, nothing. Some way for adding trusted certificates is needed. This could be achieved by coping these certificate files to certain directory (like .dillo/certificates), although it is _maybe_ easier for user, when this can be done using some file open dialog (which will tell the dpi plugin to get the file from specified location). I think the dialog way of adding certificates is not essential (notably, because its a very rare activity).
how about adding client side certificate into the https proxy (dpi plugin), certain website might requires a client certificate (which user can obtain from them), it is good if we can allow the user to add a file certificate so or allow another level of plugin to retrieve the client certificate from like smartcard, or other entity, so the https proxy can verify the client with the server. But this happen very rare. -- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chee Bin HOH (cbhoh) iVEST Department, Mimos Bhd, Technology Park Malaysia, 57000, Kuala Lumpur, Malaysia. http://www.mimos.my http://www.ivest.com.my -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+JkDQAlAFlqwDyl4RAqrhAKClZ50SvSMPeMWYEHbGKQDnfN5FQwCg4JGH u4FBpHbJTKfskuJiS9BjP2o= =pnCn -----END PGP SIGNATURE-----
On Mon, 9 Jun 2003, CHEE BIN HOH wrote:
how about adding client side certificate into the https proxy (dpi plugin), certain website might requires a client certificate (which user can obtain from them), it is good if we can allow the user to add a file certificate so or allow another level of plugin to retrieve the client certificate from like smartcard, or other entity, so the https proxy can verify the client with the server. But this happen very rare.
This could be also done by adding files manually to separate directory (some conf file is then also needed, to associate hosts with certificates that will be used, when connecting to them). And i think, that if someone wants a gui for adding them, this (gui) could be very well done later using a separate plugin. -- mzz
participants (2)
-
CHEE BIN HOH -
madis