Re: The OpenSSL API

On Sat, 18 Aug 2007 18:08:08 +0000, phil-news-nospam wrote:

On Fri, 17 Aug 2007 08:51:33 -0000 Harold Weissman
<HaroldW22@xxxxxxxxxxx> wrote:

| Those examples are interesting, but they do not address the |
question. First, if I have an application and want for it communicate |
securely with a remote partner, I would like to have access to something
| as close to a black box to do it for me. As you imply, that might not
be | possible; but, between the black box approach and the gory-detail
OpenSSL | approach there is a lot of room.

There is also no one best kind of security for all applications and
users. There are many different kinds of black boxes. Which one would
you like to use?

How does this justify the complexity of the OpenSSL API?


| Second, could you point out what applications do not fit the |
simple API mentioned above? The idea is, like I said, to send and
receive | data securely, but having to deal as little as possible with
the | underlying protocol (we don't have to know TCP/IP to send data
reliably, | and we don't have to know assembler to program a computer,
in general.) | Granted that there are a lot of choices in the SSL realm
but, for the | most part, they do not have to do with the SSL protocols
themselves.

Define "securly". Do you want to prevent someone from seeing the data
you exchange with someone else? Do you want to be sure you actually are
communicating with that person as opposed to an imposter?

The SSL protocol takes care of the first by means of a session
key exchange (based on Diffie-Hellman, or some other key exchange
mechanism) and of the second by means of the certificates that are
exchanged during the handshake. Again, all this stuff can be done (and
should be done) in a way almos completely transparent to the application
developer.

One critical issue in security is the man-in-the-middle attack. Someone
can interpose a facility between you and the person you want to
communicate securely with. They fake the other party's IP address and
exchange keys with you. Then they initiate the communication to that
other party and do the key exchange there (not the same keys). Now you
can send data to and get data from the intended party, but the
man-in-the-middle sees it all in the clear, and can even modify it.

The SSL protocol is designed to make the man-in-the-middle attack
impractical, if not impossible. And, again, nothing to do with my
original question. I am _not_complaining about the protocol, but about
the overcomplicated API exposed by OpenSSL.


One solution to that might seem to be pre-exchanged keys. But how do
you do _that_ securely? You might have to meet face-to-face in some
dark alley and trade flash keys. This can be practical for friends, but
not for the world in general.

Another solution is a public key facility. This widens the scope a bit.
But you don't really know a public key is truly from the person they say
it is unless you get a signed key signed by someone you already have a
public key for that you trust.

All contemplated in SSL - and nothing to do with OpenSSL.

| Third, a more complicated API does not increase security. In |
fact, the opposite is likely to be true. E.g., how does the fact that |
there are two different interfaces within the OpenSSL API increase its |
security?

This is very true. Security is a difficult juggle between the
complexity that exposes errors and misunderstanding, and the need to fit
and match the security to the specific needs.

Security could be far, far more complex than the OpenSSL API is. But
the general users still do need a certain level of variety in handling
things.

Like what? Please describe an application that could not make do
with the simple SSL API that I described above.

And there are programming issues, too, so the APIs have to be able to
deal with things like reentrancy and threading. So you end up creating
objects and manipulating the state in those objects.

Which would of course be easier with the simple API described
than with the complex OpenSSL one.

| Fourth, the Diebold example is interesting, because it |
illustrates that using OpenSSL would not have prevented it - We are |
talking sheer incompetence on Diebold's side. Indeed, this is the kind
of | thing that I, as an application developer, would not even want to
know | about - the API should do such chores without my intervention, so
that I | can't make silly mistakes like that.

Which chores. The chores _you_ may need it to do might be very
different than the chores that _I_ need, vs. the chores the IRS needs,
or the chores your hospital needs.

Again, what are those chores? Does it not boil down to exchange
data securely with a party that can be authenticated unambiguously? Do
you have any specific examples that would require an API more complicated
than the simple one I described? I am not challenging you; it's just that
I would be very interested to learn about that.

| Security is difficult, but I remain unconvinced that a
humongous, | complex API like OpenSSL's does anything to improve things.
In fact, I | believe the opposite is true.

OpenSSL is not the most secure facility, nor is it the easiest. It may
be the best balance of the two for the most people. Half will find it
to be more complicated and the other half will find it lacking in
flexibility.

For example, I want to be sure that _my_ program gets the encrypted data
stream back so I can then encapsulate it inside chunks of another
protocol even those your need could be as simple as letting OpenSSL do
all the read and write operations on a socket. Some programmers might
be fine with the handoff of the encrypted stream to be done through
callbacks, but that is a complicating factor, too. Things I need to do
might end up winding up the call stack too tighly, so I want the
encrypted stream via a return.

Then you have to deal with the choices of what cipher to use (weak ones
for high data volume that doesn't have such critical security needs or
strong ones for lesser data volume that is crucially in need of
secrecy),

This is VERY simple stuff. It does not require anything remotely
close in complexity to OpenSSL. Also, why would you want to have weak
ones for some data? Currently, AES tends to run faster than just about
anything else; using something weaker (like DES) would cause your
application to run more slowly.

and how to handle authentication. Is that certificate
recevied from the other end signed by someone you trust, or signed by
someone that is trusted by someone you trust?

Easily done inside the protocol via configuration files (or
embedded data) without any knowledge required from the application
programmer.


Programming _itself_ is complicated, and OpenSSL is quite vulnerable to
just that need even before we consider all the needs for encryption and
authentication. And then there are denial of service attacks which are
just as complex to work around.

Unusurpringly so, given the complexity of the API.

Take a look at IPsec. From a programming perspective that might seem
like a simple way to engage some security. The program only needs to
just open the connection and it is secured ... if the adminstrators on
both ends got the configuration right. The program may never know.
This is one of the reasons Bruce Schneier and others have called for
removal of AH and transport mode from IPsec.

IPSec is kernel-invasive and a one-size-fits-all kind of
solution. This does not make it desirable in all cases.

Your points are well taken, but they do not even remotely justify
why the OpenSSL is so complicated.

.

Relevant Pages

  • Re: The OpenSSL API
    ... Complexity exists from flexibility. ... I think that is the case with OpenSSL. ... |> not see or understand what you think a simpler API could be like. ... |> a time consuming task (to go through all possible SSL needs). ...
    (comp.os.linux.networking)
  • Re: The OpenSSL API
    ... | OpenSSL forces one to do all too often. ... application does not need to handle its own security contexts, ... such from the API? ... it is a "just right" level of complexity. ...
    (comp.os.linux.networking)
  • Re: The OpenSSL API
    ... gory-detail OpenSSL approach there is a lot of room. ... simple API mentioned above? ... Granted that there are a lot of choices in the SSL realm but, ... every secure application I have ever written doesn't fit the ...
    (comp.os.linux.networking)
  • The OpenSSL API
    ... Can anybody in this forum explain why the API exposed by OpenSSL ... One for establishing the secure channel, ... afforded by the protocol, without having to know anything much (or at ...
    (comp.os.linux.networking)
  • Re: The OpenSSL API
    ... The short answer is that security is complicated. ... would naively thought that an API with four calls would be enough: ... and one for terminating the secure channel. ... Even using a library like OpenSSL that tries as hard as it can ...
    (comp.os.linux.networking)