Re: [twsocket] THttpCli digest and basic authentication
Maurizio, Something like that is required, also because current authentication code in the THttpCli is a complicated nightmare, error-prone and contains plenty of duplicated code. I know it very well :-) I already post in the past my propose of changes, but probably it was not the right moment because I got no feedback. Well done! I think I can merge your code with ICS v7 next week and add digest authentication. The demo should then be extended to show how to preemptively send Authorization headers. In order get this working with digest wee need the realm, nonce and opaque values from the challenge as well as HTTP method, the digest URI and a nonce count value which has to be incremented on each request actually received by the server. -- Arno -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] NIC list
Indeed if a spy is observing packets from the beginning of session this will not work, I was certainly drunk when I posted ;) If I don't want to use https , given the fact I control the source of both client and server , is there any alternative mechanism I can use to avoid fake messages from clients ? - Original Message - From: Florin Vancea fvan...@maxiq.ro To: ICS support mailing twsocket@elists.org Sent: Friday, January 16, 2009 7:23 AM Subject: Re: [twsocket] NIC list Anyone capturing the session ID will capture the IP you send, too. If you are concerned about security, use https with your cookies. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] NIC list
You will need to implement some sort of signature along with all your messages. If the actual security requirements are light (i.e. protection against the casual hacker) then you could hash every message combined with a value specific to each client, then include the hash along with the message. On server side, you repeat the process and check the incoming hash against the resulting one. Obviously you will need a value specific to each client, which should be reasonably hard to get for the intruder. To generate one you could use Diffie-Hellman or something similar (in Javascript? over HTTP? auch!) or you could simply send a random value from the client with the first request and hope the intruder was not there to see it :) Please note that this single vulnerable message is only slightly better than no protection at all (the cookie is visible in each request, the random value only once). For any stronger security concerns than the above scenario I would strongly recommend the beaten path, i.e. https, against any home-brewed protocol. HTH. - Original Message - From: scconsulting scconsult...@free.fr To: ICS support mailing twsocket@elists.org Sent: Friday, January 16, 2009 1:57 PM Subject: Re: [twsocket] NIC list Indeed if a spy is observing packets from the beginning of session this will not work, I was certainly drunk when I posted ;) If I don't want to use https , given the fact I control the source of both client and server , is there any alternative mechanism I can use to avoid fake messages from clients ? - Original Message - From: Florin Vancea fvan...@maxiq.ro To: ICS support mailing twsocket@elists.org Sent: Friday, January 16, 2009 7:23 AM Subject: Re: [twsocket] NIC list Anyone capturing the session ID will capture the IP you send, too. If you are concerned about security, use https with your cookies. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Cannot load libeay32
Hi guys, I am having a strange problem, wrote an example application just connect to a gmail account and checks new mail, it works fine on a computer and when I move to another says it cannot load libeay.32.dll. Libeay32 is in the same folder with the application, the only visible difference between the 2 pc is that one has windws xp pro italian, the other has windows xp home german. Any suggestion ? Thanks! -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Cannot load libeay32
when I move to another says it cannot load libeay.32.dll. Most OpenSLL DLLs are dependent upon a Microsoft redistributable DDL, msvcr71.dll. You probably have it already on your PC, but not on the other. Add it to your distribution, in the same directory as the OpenSLL DLLs. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Cannot load libeay32
Marco Pavanelli wrote: I am trying to write an example app in c++ builder 6 that works ok on my computer but on 2 other computer does not work, the error I get is an error of missing LIBEAY32 but the libeay is there, so I added som debug code near the loadlibrary function in icsLIBEAY and the loadlibrary fails with an error 14001, which seems to mean that another dll is missing from windows. Do you have any idea about what is causing this ? Yes, you either should compile your own libraries with Mingw or find some DLLs built without those MS dependencies. AFAIK the Subversion distribution includes clean DLLs (FileZilla maybe as well). Use MS Dependency Walker to inspect the DLLs in question. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS SSL problem with libeay32
Marco Pavanelli wrote: I tried to copy msvcr71.dll in the same folder with application and libeay but nothing changes, I tried to look for the libeay in the SVN but I could not find it, in filezilla folders I have foung a mingw dll but I do not understand I should I use that ? Now I try the last suggestion, the ms dependency walker. I did not mean the ICS repository but the Subversion software distribution. but I could not find it, in filezilla folders I have foung a mingw dll I see, obviously current FileZilla versions do no longer link the OpenSSL DLLs. I just got a bounce from your gmail server which did not accept the zipped OpenSSL binaries attached to my PM. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpCli digest and basic authentication
Scrive Arno Garrels arno.garr...@gmx.de: Maurizio, Arno, Something like that is required, also because current authentication code in the THttpCli is a complicated nightmare, error-prone and contains plenty of duplicated code. I know it very well :-) I already post in the past my propose of changes, but probably it was not the right moment because I got no feedback. Well done! I think I can merge your code with ICS v7 next week and add digest authentication. If you already added the Digest to the client then I suggest to do the merge using the version without it. I hope that at the end all code that actually is not used by the new authentication handling will be removed. Otherwise we continue to have two different code into a single source and maintain both will be a nightmare. The Digest authentication support must be in a different unit. The demo should then be extended to show how to preemptively send Authorization headers. At the end yes. In order get this working with digest wee need the realm, nonce and opaque values from the challenge as well as HTTP method, the digest URI and a nonce count value which has to be incremented on each request actually received by the server. This is done by the class that handle the specific authentication. After the component has selected which scheme will be used (the strongest one) it will initialized using the specific header line sent by the server. About the merge, I suggest to done it just to be a bit confident with the new authentication handling. But not make it official for the moment since I want to change it and this will certainly mean that some classes, events an so on will be different, introducing backward compatibility if the actual will be released. Mainly what I want to do is: - add a way to authenticate without first receiving a 401/401 status code - handle different realms sent form the server - add a way to tell the component which proxy should use. I hope that I start to work on it very very soon. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
