Re: strong TLS connections
Our monolithic program (which runs in well under a meg including the program and all memory it uses) is monitored for correct hash (an algorithm we have to give a 21 byte hash total of files for which I have never seen two different files with the same hash) from an off-site program AND onsite cron processes. It also has calls within itself to validate it has not been de-compiled and modified. It has timing alerts that make using gdb/dbx with break points virtually impossible. It is also tied to the serial number of the AIX box or network card address on others. If even one byte does not match what was sent, email alerts are sent, the program is removed (after document user ids dates and times), the port is disabled, and so forth. Nothing is impenetrable, but an ordinary patching is not going to do the job. Secondly, dynamic libraries if shared by say 10 programs could be modified for some purpose OTHER than my program. They may be debugging their software, and hence write a log file of data, not realizing that they are logging my raw credit card data. My software then becomes non-compliant due to the innocent actions of others. Or their software may require a certain version that has a vulnerability that I can't live with. And I don't want to have to monitor this. Third, I certify my software with the static link. I know -- and the PCI compliance auditors know -- that it is compliant. If I have no control over dynamic libraries I have no way of KNOWING I am compliant in that environment. Neither does the customer or the auditor. Stray debug logging is, in fact, one of the primary causes of non-PCI compliance. Fourth, I use different compiler switches than the open source (different thread choices, different one-char default behavior, etc). How that works without a static link is an open question (and there are many other issues). The point of a static link is that ... it is static. You know what your program will do and you know how it will behave and you have tested, certified, and deployed in that manner. It is easy to validate that it has not been harassed. The point of a dynamic link is to allow O/S updates that fix perceived bugs/holes. In some situations this may not be a good thing (like say in my stray debug example). And usually not relevant. I might be using only one particular encryption. The fixes might be for others. And ... as usual with all software, sometimes fixes also have unintended consequences. I still think that the highest security is achieved with a static link. The easiest to keep current and updated is obviously the dynamic link. So that balance should be what decides. E At 12:13 PM 10/30/2011, you wrote: There are taste issues on this -- but you may be happier with a static link. It will load a giga-blip faster too with static link, and you won't even notice :-) A lot will depend on what your software is and how much of it. We have thousands of customers. We do credit cards which requires certification and you cannot (should not) allow the customer to change your software by installing a dynamic library. In fact, what if they built themselves their own libraries that wrote the unencrypted text out to a file? Then they could steal credit card numbers. BAD BAD BAD. It is a security hole to allow dynamic libraries because you have no control on what is really there. If the code is running at the customer site, you have no control over it, whether it's static or dynamic linked. It might be a giga-blip easier for your customer/attacker to patch a dll, put it's still trivial to patch your monolithic program. Eric S. Eberhard (928) 567-3727 Voice (928) 567-6122 Fax (928) 301-7537 Cell Vertical Integrated Computer Systems, LLC Metropolis Support, LLC For Metropolis support and VICS MBA Supporthttp://www.vicsmba.com For pictures: http://www.vicsmba.com/ourpics/index.html (You can see why we love this state :-) ) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
After all my wrangling, I'm leaning towards just using client certs. Is it a reasonable assumption that on UNIX'es these days I can expect to find libssl.so AND the openssl command line? If not, is it reasonable to assume that A sysadmin will install openssl to get my app to work? Otherwise, it would seem that something as easy and well documented as creating a CSR could be a lot more coding... Many thanks for all the useful comments! Kris On 10/27/11 7:20 AM, Michael S. Zick wrote: On Wed October 26 2011, Kristen J. Webb wrote: Having an app that can use certs, it appears, is nothing compared with how to deploy it and manage those certs ;) A general truism not specific to certs. Recognizing (or implementing) a need for trust is one thing; Determining (or establishing) what is to be trusted is quite another. Consider: Your roof leaks. Its easy to find a contractor who claims they will fix it. Its an entirely different matter to find one you can __trust__ to do the job correctly and to your satisfaction. Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
I have an easy solution I use because not only do you have the problem with admins not having the library installed, you have the problem of them having the wrong version installed for something they need. Your app or theirs won't work. Or yours will, and they update openssl and it no longer does. And some places with strict security policies won't let you install things like openssl (but if they want your app they have to install it!). I simply build the static libraries and link them in. This means nothing need exist on the target machine and that you have a more stable product because you have tested against the library version you have static linked. You could argue it makes the program bigger and my answer is -- say what? My iPod could handle my entire business suite and data (for disk space, not actually running) -- so who cares. I have found this is often the easiest way to go. I also make a small wrapper that only builds certs from openssl and uses a different name, again making it appear to be my software. I also allow them to use a Web interface to my site to make a cert and download it. Eric At 11:09 AM 10/28/2011, Kristen J. Webb wrote: After all my wrangling, I'm leaning towards just using client certs. Is it a reasonable assumption that on UNIX'es these days I can expect to find libssl.so AND the openssl command line? If not, is it reasonable to assume that A sysadmin will install openssl to get my app to work? Otherwise, it would seem that something as easy and well documented as creating a CSR could be a lot more coding... Many thanks for all the useful comments! Kris On 10/27/11 7:20 AM, Michael S. Zick wrote: On Wed October 26 2011, Kristen J. Webb wrote: Having an app that can use certs, it appears, is nothing compared with how to deploy it and manage those certs ;) A general truism not specific to certs. Recognizing (or implementing) a need for trust is one thing; Determining (or establishing) what is to be trusted is quite another. Consider: Your roof leaks. Its easy to find a contractor who claims they will fix it. Its an entirely different matter to find one you can __trust__ to do the job correctly and to your satisfaction. Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Eric S. Eberhard (928) 567-3727 Voice (928) 567-6122 Fax (928) 301-7537 Cell Vertical Integrated Computer Systems, LLC Metropolis Support, LLC For Metropolis support and VICS MBA Supporthttp://www.vicsmba.com For pictures: http://www.vicsmba.com/ourpics/index.html (You can see why we love this state :-) ) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On 10/28/11 12:39 PM, Eric S. Eberhard wrote: I have an easy solution I use because not only do you have the problem with admins not having the library installed, you have the problem of them having the wrong version installed for something they need. Your app or theirs won't work. Or yours will, and they update openssl and it no longer does. And some places with strict security policies won't let you install things like openssl (but if they want your app they have to install it!). I simply build the static libraries and link them in. This means nothing need exist on the target machine and that you have a more stable product because you have tested against the library version you have static linked. You could argue it makes the program bigger and my answer is -- say what? My iPod could handle my entire business suite and data (for disk space, not actually running) -- so who cares. I have found this is often the easiest way to go. I also make a small wrapper that only builds certs from openssl and uses a different name, again making it appear to be my software. I also allow them to use a Web interface to my site to make a cert and download it. Eric Static linking is something that we looked at a while back. Some other folks have convinced me that static linking may not the best way to go. - You have to keep up with security updates. If you link against the system libraries, then security vulnerabilities can be handled at the OS level. OS vendors try hard not to break backward compatibility, but I suppose time will tell if this will come back to bite us ;) - I don't have a complete answer on this yet, but it would seem to me that dynamic linking against crypto libraries instead of shipping those bits (static link) would make life easier from a US export side, but I am no lawyer! - If I am not mistaken, linking against system OpenSSL libraries allows you to work around the GNU licensing conflict which had me worried early on as I looked to adopting OpenSSL. Again, I'm no lawyer! Relying on OS configuration is more difficult, especially for Linux, as I need to now build against many linux distro's to get things right. Thanks to virtual environments, this is at least manageable. At 11:09 AM 10/28/2011, Kristen J. Webb wrote: After all my wrangling, I'm leaning towards just using client certs. Is it a reasonable assumption that on UNIX'es these days I can expect to find libssl.so AND the openssl command line? If not, is it reasonable to assume that A sysadmin will install openssl to get my app to work? Otherwise, it would seem that something as easy and well documented as creating a CSR could be a lot more coding... Many thanks for all the useful comments! Kris On 10/27/11 7:20 AM, Michael S. Zick wrote: On Wed October 26 2011, Kristen J. Webb wrote: Having an app that can use certs, it appears, is nothing compared with how to deploy it and manage those certs ;) A general truism not specific to certs. Recognizing (or implementing) a need for trust is one thing; Determining (or establishing) what is to be trusted is quite another. Consider: Your roof leaks. Its easy to find a contractor who claims they will fix it. Its an entirely different matter to find one you can __trust__ to do the job correctly and to your satisfaction. Mike __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org Eric S. Eberhard (928) 567-3727 Voice (928) 567-6122 Fax (928) 301-7537 Cell Vertical Integrated Computer Systems, LLC Metropolis Support, LLC For Metropolis support and VICS MBA Support http://www.vicsmba.com For pictures: http://www.vicsmba.com/ourpics/index.html (You can see why we love this state :-) ) __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
Kristen, Your points are all good. However, I have found the compatibility not good with customer installed versions versus my own. One of the problems, for example, could be that openssl compiles with a certain type of threads, not the same as your application. Same with semaphores and who knows what else. It could be many features like that. It could be changes in product I have found. Also, if they install in a different location than you, the header of your program will not find it (which can be solved with links on the user's system, sometimes). Sometimes the user installs a version with other dependencies (for example I use libxml2 but not the libzip ... and when a customer put the libzip version in, my application had problems). So then what I was doing was putting my versions of the dynamic libraries in my own location /usr/local/application_name/lib And linking that way and installing that way. But then when the security changes came ... I had to again install something and I realized it was easier to just install the static linked software. You also get tighter testing because it will force you to get the latest version, compile it, link it, test it, then install it. I do a LOT of cross-platform (AIX, Linux, OS/X, SCO, HP/UX, Windows, etc) work and have found that I am always safer linking exactly what I want and releasing that. I guess I feel I have more control over quality this way. BUT THIS IS JUST A DUMB OPINION -- most people disagree. I have found in practice that the dream of the O/S level updates magically making security updates work for your software is a dream that is more nightmare than pleasant. But that is just me. There are others who do agree, I am not alone, but I would guess a minority. As for the export question -- if they are not allowed certain things they are not allowed. Depending on your application, it may be OK. So if you require the illegal export of strong encryption and you install or ask them to install, you and they are in trouble. If your application is, say, a credit card application -- and it is static linked and can ONLY be used to process credit cards (and you let them generate keys through you) you are in fact able to export without legal complication. I export, had legal advise. I am not sure what you mean by the GNU licensing conflict. You are still only charging for your application, whether you static or dynamic link. I do always include the proper copyright files and put them in /usr/local/lib ... even though my link is static. I checked this as well. I will tell you that both my legal checks were cursory but I am confident they were sufficient. If you are really worried, check with a lawyer. On the GNU I think it is pretty much a matter of the intent of the license anyway. If you disclose it's use, include the proper copyright/license files, and don't charge for it, I think you are fine. There are taste issues on this -- but you may be happier with a static link. It will load a giga-blip faster too with static link, and you won't even notice :-) A lot will depend on what your software is and how much of it. We have thousands of customers. We do credit cards which requires certification and you cannot (should not) allow the customer to change your software by installing a dynamic library. In fact, what if they built themselves their own libraries that wrote the unencrypted text out to a file? Then they could steal credit card numbers. BAD BAD BAD. It is a security hole to allow dynamic libraries because you have no control on what is really there. You cannot look at a customer or credit card auditor and say with a straight face that you control the encryption and there is no security leak. If you statically link something in and certify it ... it is what is is. Under current credit card rules you may do minor updates just by notifying them -- so if you find a security patch that applies to your application (most don't for me) then you download, link statically, report to everyone who needs to know, and install your app again. Eric At 12:13 PM 10/28/2011, Kristen J. Webb wrote: On 10/28/11 12:39 PM, Eric S. Eberhard wrote: I have an easy solution I use because not only do you have the problem with admins not having the library installed, you have the problem of them having the wrong version installed for something they need. Your app or theirs won't work. Or yours will, and they update openssl and it no longer does. And some places with strict security policies won't let you install things like openssl (but if they want your app they have to install it!). I simply build the static libraries and link them in. This means nothing need exist on the target machine and that you have a more stable product because you have tested against the library version you have static linked. You could argue it makes the program bigger and my answer is
Re: strong TLS connections
On 10/27/2011 2:14 AM, Kristen J. Webb wrote: On 10/8/11 1:16 AM, Michael Sierchio wrote: On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webbkw...@teradactyl.com wrote: My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. Your understanding is flawed - while in the scenario you mention there is no binding of a client identity to a public key, SSLv3/TLS are not vulnerable to MITM - no third party can manipulate the stream without being detected. Yes, thank you. Upon further investigation I find that not using client certs means that the server cannot prove the identity of the client. So I think that the attack I am looking at is more of a client impersonation, where a rouge client pretends to be the real client. All it takes (I think) is for the rouge client to have enough information about the server (e.g. our application installed) and be able to present itself to the server as the client under attack. Since the server cannot distinguish, then the rouge client could use our application to manipulate the server. It seems that the only way to help prevent this is to use client certificates to prove the identity of the client. The problem I am having with this is that managing certs for a few servers is easy, while managing it for 1000's of clients is not. I'm looking for the way around this and still keep things secure, but maybe there is not? There are two possible solutions to this problem: A. Once the client has verified the identity of the server and checked that a strong enough encryption has been chosen (not something like the old 40 bit stuff, but there are others that are no longer considered safe), it can use the encrypted channel to prove itself using any old method, such as a plaintext password (randomly generated for each non-human client). This is how many Internet sites use TLS with https. B. With appropriate attributes, the same certificate could be used as both server and client certificate. However you must be careful not to do this with a public key algorithm that is not secure in that scenario, others on this list can tell you which ones are safe and which ones not. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On Wed October 26 2011, Kristen J. Webb wrote: Having an app that can use certs, it appears, is nothing compared with how to deploy it and manage those certs ;) A general truism not specific to certs. Recognizing (or implementing) a need for trust is one thing; Determining (or establishing) what is to be trusted is quite another. Consider: Your roof leaks. Its easy to find a contractor who claims they will fix it. Its an entirely different matter to find one you can __trust__ to do the job correctly and to your satisfaction. Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On 10/8/11 1:16 AM, Michael Sierchio wrote: On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webbkw...@teradactyl.com wrote: My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. Your understanding is flawed - while in the scenario you mention there is no binding of a client identity to a public key, SSLv3/TLS are not vulnerable to MITM - no third party can manipulate the stream without being detected. Yes, thank you. Upon further investigation I find that not using client certs means that the server cannot prove the identity of the client. So I think that the attack I am looking at is more of a client impersonation, where a rouge client pretends to be the real client. All it takes (I think) is for the rouge client to have enough information about the server (e.g. our application installed) and be able to present itself to the server as the client under attack. Since the server cannot distinguish, then the rouge client could use our application to manipulate the server. It seems that the only way to help prevent this is to use client certificates to prove the identity of the client. The problem I am having with this is that managing certs for a few servers is easy, while managing it for 1000's of clients is not. I'm looking for the way around this and still keep things secure, but maybe there is not? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On 7 Oct 2011, at 7:40 PM, Kristen J. Webb wrote: I'm exploring the security of TLS for TCP/IP connections. I would like to establish TLS connections using server certificates (managing client certs via external or internal PKI is painful). My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. My question is, if multiple servers are used, can this attack (and possibly others) be avoided? Example: initiate_server: TLS connect with client initiate_server: send encrypted data over TLS to client (including target_server:port) initiate server: TLS connect with target_server initiate_server: send encrypted data over TLS to target_server (including listen port, client, etc) client: attempt TLS connection to target_server:port target_server: accept TLS connection from client client/target_server: verify additional encrypted data (from initiate_server) to establish a connection If I understand this, you're trying to use 'initiate_server' to introduce the other two machines to each other, and relying on those two machines' server certificates to allow initiate_server to verify that it's talking to the right machine? I see two problems with this. One is that initiate_server isn't authenticated to the other machines--- evil_server could connect to target_server, give it fake encrypted data and client info, and then impersonate the client. The other problem is that this isn't really avoiding having a certificate on the client machine. If you have a trustowrthy certificate on client, which initiate_server can use to authenticate the connection, why not use that certificate as a client certificate when client connects to target_server (and eliminate the role of initiate_server entirely)? Apologies if I don't understand your original motivation, but I don't see how the introducer scheme helps you any. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On 10/26/11 6:35 PM, Wim Lewis wrote: On 7 Oct 2011, at 7:40 PM, Kristen J. Webb wrote: I'm exploring the security of TLS for TCP/IP connections. I would like to establish TLS connections using server certificates (managing client certs via external or internal PKI is painful). My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. My question is, if multiple servers are used, can this attack (and possibly others) be avoided? Example: initiate_server: TLS connect with client initiate_server: send encrypted data over TLS to client (including target_server:port) initiate server: TLS connect with target_server initiate_server: send encrypted data over TLS to target_server (including listen port, client, etc) client: attempt TLS connection to target_server:port target_server: accept TLS connection from client client/target_server: verify additional encrypted data (from initiate_server) to establish a connection If I understand this, you're trying to use 'initiate_server' to introduce the other two machines to each other, and relying on those two machines' server certificates to allow initiate_server to verify that it's talking to the right machine? Not exactly, I was trying to develop a method where the transaction could occur securely w/o a client certificate. I am beginning to believe that this is not possible. The original idea I had is starting to look like a twisted/reverse way that Kerberos does these things (I have implemented GSSAPI using host principles, which takes the need of the client cert out of the process). I see two problems with this. One is that initiate_server isn't authenticated to the other machines--- evil_server could connect to target_server, give it fake encrypted data and client info, and then impersonate the client. I was assuming that the clients (and servers) would have the longer term trust of the initiate_server via a PEM file that has it's identity. The other problem is that this isn't really avoiding having a certificate on the client machine. If you have a trustowrthy certificate on client, which initiate_server can use to authenticate the connection, why not use that certificate as a client certificate when client connects to target_server (and eliminate the role of initiate_server entirely)? Yeah, I wish I did not need to manage the client certificates. I am interested in setting up a local CA for client certs. One of my stumbling blocks is how to manage the install of a new client with libssl.so, but not openssl installed (so openssl req not there). Apologies if I don't understand your original motivation, but I don't see how the introducer scheme helps you any. If my understanding is up to speed you need to manage client certs to do this right. Which brings me to my next set of questions about how to manage this from install to revocation. Having an app that can use certs, it appears, is nothing compared with how to deploy it and manage those certs ;) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webb kw...@teradactyl.com wrote: My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. Your understanding is flawed - while in the scenario you mention there is no binding of a client identity to a public key, SSLv3/TLS are not vulnerable to MITM - no third party can manipulate the stream without being detected. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
strong TLS connections
Hi All, I'm exploring the security of TLS for TCP/IP connections. I would like to establish TLS connections using server certificates (managing client certs via external or internal PKI is painful). My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. My question is, if multiple servers are used, can this attack (and possibly others) be avoided? Example: initiate_server: TLS connect with client initiate_server: send encrypted data over TLS to client (including target_server:port) initiate server: TLS connect with target_server initiate_server: send encrypted data over TLS to target_server (including listen port, client, etc) client: attempt TLS connection to target_server:port target_server: accept TLS connection from client client/target_server: verify additional encrypted data (from initiate_server) to establish a connection My apologies if this is obviously weak. I could not find much info on the web related to this type of multi-connection approach using TLS. Kris -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
