gib...@wsu.edu (Gibney, Dave) writes: > You are not correct. You can make SSL optional and therefore clear if > it is not used, if the connection is secure, all data (including > Userid/password) is encrypted.
re: http://www.garlic.com/~lynn/2009m.html#5 Need new 3270 emulator: SSH, inexpensive, reliable most SSL implementations just has the client validating the server's digital certificate and then validating whether or not the domain name claimed in the digital certificate corresponds to the domain name in the URL used to contact the server (countermeasure to ip-address hijacking). then the server's public key is used to exchange a symmetric key ... for encryption of the actual session (des, aes, blowfish, whatever). then, once the encrypted session is established, client typically presents userid/password for authentication. we had been called in to consult with a small client/server startup that wanted to do payment transactions on their server ... and the startup had invented this technology called SSL that they wanted to use. As part of that deployment ... now frequently called "electronic commerce" ... we had to investigate some number of these new operations called "Certification Authorities" that were issuing things called "digital certificates". Also as part of deploying a payment gateway ... requiring SSL for payment transactions between the webserver and the payment network ... we mandated "mutual authentication" ... which hadn't yet been implemented at the time (aka client does public key authentication of the server ... and the server does public key authnetication of the client ... no passwords). By the time we were done ... the payment gateway operation looked much more like SSH ... since both the payment gateway and the webservers had preregistered information about each other (the things called "digital certificates" became purely artificial side-effect of the SSL code library being used). misc. past posts mentioning original payment gateway deployment http://www.garlic.com/~lynn/subnetwork.html#gateway SSH has the advantage (compared to typical SSL use) that both parties does "mutual" public key authentication of the other party w/o requiring digital certificates and w/o requiring passwords. some number of generic past posts mentioning public key operations w/o using (redundant and superfluous) digital certificates. http://www.garlic.com/~lynn/subpubkey.html#certless the other issue with SSL ... was that there were some number of requirements about how it was implemented and deployed in order to satisfy security requirements ... many of which were almost immediately violated ... and have subsequently, over the past 15 yrs or so ... have led to a whole lot of exploits and compromises. part of it involves the complexity and indirection introduced by these things called "digital certificates". some number of past posts mentioning SSL (domain name) digital certificates http://www.garlic.com/~lynn/subpubkey.html#sslcerts and from long ago and far away ... nearly three decade old email discussing for a PGP-like (certificate-less) public key implementation on the internal network: http://www.garlic.com/~lynn/2007d.html#email810506 http://www.garlic.com/~lynn/2006w.html#email810516 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
