strong TLS connections

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

strong TLS connections

Kristen J. Webb
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: [hidden email]
VISIT: http://www.teradactyl.com

  Home of the

  True incremental Backup System
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Michael Sierchio
On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webb <[hidden email]> 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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Kristen J. Webb


On 10/8/11 1:16 AM, Michael Sierchio wrote:

> On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webb<[hidden email]>  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 List                    [hidden email]
> Automated List Manager                           [hidden email]
>

--
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: [hidden email]
VISIT: http://www.teradactyl.com

  Home of the

  True incremental Backup System
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Wim Lewis-3
In reply to this post by Kristen J. Webb

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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Kristen J. Webb


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 List                    [hidden email]
> Automated List Manager                           [hidden email]
>

--
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: [hidden email]
VISIT: http://www.teradactyl.com

  Home of the

  True incremental Backup System
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Jakob Bohm-7
In reply to this post by Kristen J. Webb
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.
>> Webb<[hidden email]>  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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Michael S. Zick-4
In reply to this post by Kristen J. Webb
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Kristen J. Webb
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                    [hidden email]
> Automated List Manager                           [hidden email]
>

--
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: [hidden email]
VISIT: http://www.teradactyl.com

  Home of the

  True incremental Backup System
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Eric S. Eberhard-2
In reply to this post by Michael S. Zick-4
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 List                    [hidden email]
>>Automated List Manager                           [hidden email]
>
>--
>Mr. Kristen J. Webb
>Teradactyl LLC.
>
>PHONE: 1-505-242-1091
>EMAIL: [hidden email]
>VISIT: http://www.teradactyl.com
>
>         Home of the
>
>  True incremental Backup System
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>User Support Mailing List                    [hidden email]
>Automated List Manager                           [hidden email]


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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Kristen J. Webb


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 [hidden email]
>>> Automated List Manager [hidden email]
>>
>> --
>> Mr. Kristen J. Webb
>> Teradactyl LLC.
>>
>> PHONE: 1-505-242-1091
>> EMAIL: [hidden email]
>> VISIT: http://www.teradactyl.com
>>
>> Home of the
>>
>> True incremental Backup System
>> ______________________________________________________________________
>> OpenSSL Project http://www.openssl.org
>> User Support Mailing List [hidden email]
>> Automated List Manager [hidden email]
>
>
> 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 [hidden email]
> Automated List Manager [hidden email]
>

--
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: [hidden email]
VISIT: http://www.teradactyl.com

  Home of the

  True incremental Backup System
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Eric S. Eberhard-2
In reply to this post by Eric S. Eberhard-2
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 -- 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 [hidden email]
>>>>Automated List Manager [hidden email]
>>>
>>>--
>>>Mr. Kristen J. Webb
>>>Teradactyl LLC.
>>>
>>>PHONE: 1-505-242-1091
>>>EMAIL: [hidden email]
>>>VISIT: http://www.teradactyl.com
>>>
>>>Home of the
>>>
>>>True incremental Backup System
>>>______________________________________________________________________
>>>OpenSSL Project http://www.openssl.org
>>>User Support Mailing List [hidden email]
>>>Automated List Manager [hidden email]
>>
>>
>>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 [hidden email]
>>Automated List Manager [hidden email]
>
>--
>Mr. Kristen J. Webb
>Teradactyl LLC.
>
>PHONE: 1-505-242-1091
>EMAIL: [hidden email]
>VISIT: http://www.teradactyl.com
>
>         Home of the
>
>  True incremental Backup System


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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: strong TLS connections

Eric S. Eberhard-2
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 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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

OpenSSL security issues and FIPS.

Gerald L Collins
In reply to this post by Michael S. Zick-4
Hello all,
  I've been tasked to look at some security issues for our OpenSSL implementation.  We are currently at FIPS 1.2.2 and openssl 0.9.8k.  Most of the issues I was asked to look at were no issue for us, but the below item I'm less certain about.  Since we are FIPS does this have any chance of affecting us?  We do use the SSLv23_server method in the call of SSL_CTX_new.



Uninitialized SSL 3.0 Padding - (CVE-2011-4576):  
OpenSSL prior to 1.0.0f and 0.9.8s failed to clear the bytes used as block
cipher padding in SSL 3.0 records. This affects both clients and servers
that accept SSL 3.0 handshakes: those that call SSL_CTX_new with
SSLv3_{server|client}_method or SSLv23_{server|client}_method. It does not
affect TLS. As a result, in each record, up to 15 bytes of uninitialized
memory may be sent, encrypted, to the SSL peer. This could include sensitive
contents of previously freed memory. However, in practice, most deployments
do not use SSL_MODE_RELEASE_BUFFERS and therefore have a single write buffer
per connection. That write buffer is partially filled with non-sensitive,
handshake data at the beginning of the connection and, thereafter, only
records which are longer any any previously sent record leak any
non-encrypted data. This, combined with the small number of bytes leaked per
record, serves to limit to severity of this issue.


Thanks,
Jerry

Gerald Collins
Senior Member Technical Staff, Programmer / Analyst
CSC

8 Executive Drive, Suite 300, Fairview Heights, IL 62208 North American Public Sector | p: +1-618-632-9252 x410  | | [hidden email] |
www.csc.com



This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL security issues and FIPS.

Jakob Bohm-7
General reminder:  If you (mis)use the "Reply" button
in your e-mail program to start a new topic, many
recipients and automated e-mail archiving systems will
file your e-mail under the case/topic of the mail you
"replied" to.

This is because your e-mail program (correctly) includes
the unique message-id of the replied-to e-mail in the
reply specifically to facilitate correct sorting and
filing of replies.

As for your question, from the description you quote
below, I would presume this issue to be outside the
FIPS-certified part of OpenSSL and thus affecting
anyone using version 0.9.8q or older with or without
the FIPS module.  Upgrading to the latest 0.9.8-series
release (at least 0.9.8s for this particular issue) in
combination with the existing FIPS-certified
"FIPS-canister" is probably the appropriate response.

On 1/25/2012 4:04 PM, Gerald L Collins wrote:

> Hello all,
>   I've been tasked to look at some security issues for our OpenSSL
> implementation.  We are currently at FIPS 1.2.2 and openssl 0.9.8k.
>  Most of the issues I was asked to look at were no issue for us, but
> the below item I'm less certain about.  Since we are FIPS does this
> have any chance of affecting us?  We do use the SSLv23_server method
> in the call of SSL_CTX_new.
>
>
>
> Uninitialized SSL 3.0 Padding - (CVE-2011-4576):
> OpenSSL prior to 1.0.0f and 0.9.8s failed to clear the bytes used as
> block
> cipher padding in SSL 3.0 records. This affects both clients and servers
> that accept SSL 3.0 handshakes: those that call SSL_CTX_new with
> SSLv3_{server|client}_method or SSLv23_{server|client}_method. It does
> not
> affect TLS. As a result, in each record, up to 15 bytes of uninitialized
> memory may be sent, encrypted, to the SSL peer. This could include
> sensitive
> contents of previously freed memory. However, in practice, most
> deployments
> do not use SSL_MODE_RELEASE_BUFFERS and therefore have a single write
> buffer
> per connection. That write buffer is partially filled with non-sensitive,
> handshake data at the beginning of the connection and, thereafter, only
> records which are longer any any previously sent record leak any
> non-encrypted data. This, combined with the small number of bytes
> leaked per
> record, serves to limit to severity of this issue.
>
>
> Thanks,
> Jerry
>
> Gerald Collins
> Senior Member Technical Staff, Programmer / Analyst
> CSC
>
> 8 Executive Drive, Suite 300, Fairview Heights, IL 62208 North
> American Public Sector | p: +1-618-632-9252 x410  | | [hidden email]
> | www.csc.com <www.csc.com>
>
>
>
> This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC
> to any order or other contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of
> e-mail for such purpose.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL security issues and FIPS.

Dr. Stephen Henson
In reply to this post by Gerald L Collins
On Wed, Jan 25, 2012, Gerald L Collins wrote:

> Hello all,
>   I've been tasked to look at some security issues for our OpenSSL
> implementation.  We are currently at FIPS 1.2.2 and openssl 0.9.8k.  Most
> of the issues I was asked to look at were no issue for us, but the below
> item I'm less certain about.  Since we are FIPS does this have any chance
> of affecting us?  We do use the SSLv23_server method in the call of
> SSL_CTX_new.
>

If you enter FIPS mode then SSL v3 is not permitted so you are not affected.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL security issues and FIPS.

Gerald L Collins
Thanks Stephen,
  That was my suspicion, but I couldn't be sure.  

Gerald Collins
Senior Member Technical Staff, Programmer / Analyst
CSC

8 Executive Drive, Suite 300, Fairview Heights, IL 62208 North American Public Sector | p: +1-618-632-9252 x410  | | [hidden email] |
www.csc.com



This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.




From:        "Dr. Stephen Henson" <[hidden email]>
To:        [hidden email]
Date:        01/25/2012 12:44 PM
Subject:        Re: OpenSSL security issues and FIPS.
Sent by:        [hidden email]




On Wed, Jan 25, 2012, Gerald L Collins wrote:

> Hello all,
>   I've been tasked to look at some security issues for our OpenSSL
> implementation.  We are currently at FIPS 1.2.2 and openssl 0.9.8k.  Most
> of the issues I was asked to look at were no issue for us, but the below
> item I'm less certain about.  Since we are FIPS does this have any chance
> of affecting us?  We do use the SSLv23_server method in the call of
> SSL_CTX_new.
>

If you enter FIPS mode then SSL v3 is not permitted so you are not affected.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see:
http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                
http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]