The OpenSSL API

Can anybody in this forum explain why the API exposed by OpenSSL
is so complicated? I am thinking from the point of view of an application
A that wishes to exchange data securely with some remote application B
using SSL. I would naively thought that an API with four calls would be
enough: One for establishing the secure channel, another for sending
data, another for receiving data, and one for terminating the secure
channel.

In my view, the application developer only wants to use security
afforded by the protocol, without having to know anything much (or at
all) about the protocol itself - after all, when doing sockets
programming, one does not have know much about TCP/IP, right? However,
the OpenSSL API forces application developers to do many of the protocol
chores by hand, so to speak.

Since the designers of the OpenSSL are clearly not stupid, I must
be missing something important here. What is it?

On Aug 16, 3:27 am, Harold Weissman <Harold...@hotmail.com> wrote:

> Can anybody in this forum explain why the API exposed by OpenSSL
> is so complicated?

The short answer is that security is complicated.

> I am thinking from the point of view of an application
> A that wishes to exchange data securely with some remote application B
> using SSL. I would naively thought that an API with four calls would be
> enough: One for establishing the secure channel, another for sending
> data, another for receiving data, and one for terminating the secure
> channel.

Perhaps a niche solution that supported only a single application and
security model could be made that simple.

> In my view, the application developer only wants to use security
> afforded by the protocol, without having to know anything much (or at
> all) about the protocol itself - after all, when doing sockets
> programming, one does not have know much about TCP/IP, right? However,
> the OpenSSL API forces application developers to do many of the protocol
> chores by hand, so to speak.

I'm afraid that painful experience has proven that it is impossible to
produce a secure application without being an expert in computer
security. Even using a library like OpenSSL that tries as hard as it
can to make it easy, there are still so many ways that you can screw
it up. You need someone who has already made all those mistakes.

> Since the designers of the OpenSSL are clearly not stupid, I must
> be missing something important here. What is it?

What you are missing is that computer security is so hard that secure
applications require a computer security expert to at least review
their design and guide their implementation.

I could give you a list of examples, but one should be enough. Diebold
screwed up RSA signatures in their voting machines by comparing only
160-bits of the signature since they used a 160-bit hash. (See section
3.5)
http://election.dos.state.fl.us/pdf/...ningLetter.pdf

DS

On Thu, 16 Aug 2007 11:49:07 -0700, David Schwartz wrote:

> On Aug 16, 3:27 am, Harold Weissman <Harold...@hotmail.com> wrote:
>
>> Can anybody in this forum explain why the API exposed by
>> OpenSSL
>> is so complicated?
>
> The short answer is that security is complicated.
>
>> I am thinking from the point of view of an application A that wishes to
>> exchange data securely with some remote application B using SSL. I
>> would naively thought that an API with four calls would be enough: One
>> for establishing the secure channel, another for sending data, another
>> for receiving data, and one for terminating the secure channel.
>
> Perhaps a niche solution that supported only a single application and
> security model could be made that simple.
>
>> In my view, the application developer only wants to use
>> security
>> afforded by the protocol, without having to know anything much (or at
>> all) about the protocol itself - after all, when doing sockets
>> programming, one does not have know much about TCP/IP, right? However,
>> the OpenSSL API forces application developers to do many of the
>> protocol chores by hand, so to speak.
>
> I'm afraid that painful experience has proven that it is impossible to
> produce a secure application without being an expert in computer
> security. Even using a library like OpenSSL that tries as hard as it can
> to make it easy, there are still so many ways that you can screw it up.
> You need someone who has already made all those mistakes.
>
>> Since the designers of the OpenSSL are clearly not stupid, I
>> must
>> be missing something important here. What is it?
>
> What you are missing is that computer security is so hard that secure
> applications require a computer security expert to at least review their
> design and guide their implementation.
>
> I could give you a list of examples, but one should be enough. Diebold
> screwed up RSA signatures in their voting machines by comparing only
> 160-bits of the signature since they used a 160-bit hash. (See section
> 3.5)
> http://election.dos.state.fl.us/pdf/...ningLetter.pdf

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.

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.

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?

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.

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.

On Fri, 17 Aug 2007 08:51:33 -0000 Harold Weissman <(E-Mail Removed)> 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?


| 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?

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.

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.


| 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.

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.


| 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.


| 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),
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?

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.

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.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-18-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

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

> On Fri, 17 Aug 2007 08:51:33 -0000 Harold Weissman
> <(E-Mail Removed)> 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.

On Aug 17, 1:51 am, Harold Weissman <Harold...@hotmail.com> 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.

I don't think so. If you're right, and everybody else is wrong, you'll
have to prove it to convince us.

> 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.

Well, every secure application I have ever written doesn't fit the
simple API. The list of things you need to do outside that model
depends upon the specific application, but here are just a few:

1) You may need to get a certificate from the client.

2) You may need to check to see if the server's certificate has been
revoked.

3) You may need to parse the server's certificate to see if it's
suitable for the purpose you intend to use it for.

4) You may need to parse the server's certificate to display it to the
user.

5) You may need to handle the network I/O yourself, and as a result,
the SSL library won't be able to figure out whether this is a
resumable session without your help.

> 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?

I think you misstate my argument. I am saying that a complex API is
needed because security is complex. A simpler API would necessarily
leave out quite a bit of things that are needed to implement a secure
program.

Not all the API complexity is due to security needs. Some of it is due
to performance needs.

What "two different interfaces" are you talking about?

> 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.

Using OpenSSL would likely have prevented it because the RSA_verify
takes the length of the thing to verify and handles padding correctly.
However, a simpler API that made you do the comparison would have
allowed Diebold's mistake.

> 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.

Obviously, I disagree. If you think you can simplify the API without
compromising security, flexibility, or performance, by all means do so
and everyone will thank you.

DS

On Sat, 18 Aug 2007 21:36:40 -0700, David Schwartz wrote:

> On Aug 17, 1:51 am, Harold Weissman <Harold...@hotmail.com> 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.
>
> I don't think so. If you're right, and everybody else is wrong, you'll
> have to prove it to convince us.
>
>> 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.
>
> Well, every secure application I have ever written doesn't fit the
> simple API. The list of things you need to do outside that model depends
> upon the specific application, but here are just a few:
>
> 1) You may need to get a certificate from the client.

The SSL protocol takes care of the low level details. You can
have a context where you specify that capability with a boolean. The
application programmer need not know about the gory details.

> 2) You may need to check to see if the server's certificate has been
> revoked.

Ditto.

> 3) You may need to parse the server's certificate to see if it's
> suitable for the purpose you intend to use it for.

Like what?

> 4) You may need to parse the server's certificate to display it to the
> user.

A valid point, simple to solve.

> 5) You may need to handle the network I/O yourself, and as a result, the
> SSL library won't be able to figure out whether this is a resumable
> session without your help.

Would you care to elaborate? If a client wants to resume a
session it only has to start a connection with a previously used session
ID. It is the job of the library to make sure that such ID is valid. What
kind of help does it need from the application programmer?

>> 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?
>
> I think you misstate my argument. I am saying that a complex API is
> needed because security is complex. A simpler API would necessarily
> leave out quite a bit of things that are needed to implement a secure
> program.

Fair enough. Would you care to elaborate? So far, specific
examples are notorious by their absence.

> Not all the API complexity is due to security needs. Some of it is due
> to performance needs.

Having to deal with relatively low level details of the SSL
protocol (something that OpenSSL forces one to do) is due to performance
needs? Would you be happy if the same were true for other network
protocols, like TCP/IP?

> What "two different interfaces" are you talking about?

Oops! I left out out something there. I meant "two different
crypto interfaces".

>> 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.
>
> Using OpenSSL would likely have prevented it because the RSA_verify
> takes the length of the thing to verify and handles padding correctly.
> However, a simpler API that made you do the comparison would have
> allowed Diebold's mistake.

Certainly not the one I proposed, for such a detail would buried
deep inside the library, where it belongs. The application programmer
could never have made such a mistake, simply because he would never have
had the chance to.

>> 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.
>
> Obviously, I disagree. If you think you can simplify the API without
> compromising security, flexibility, or performance, by all means do so
> and everyone will thank you.

The specialized literature has made similar criticisms of the
OpenSSL API. This API is the most widely used not because it is the best
around, but despite of the fact that it isn't.

On Sat, 18 Aug 2007 20:51:30 -0000 Harold Weissman <(E-Mail Removed)> wrote:

| 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.

The application may need to set parameters. And it may need to provide
the certificates, or check that of the peer, rather than just assume the
generic choices in a transparent library would suffice. One application
might need everything to be different than another application. This is
one reason quite a number of facilities should be available.


|> 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.

I don't see it as "over complicated". I see it as "very complicated"
in proprtion to the details that need to be dealt with by the application.

So, basically, I agree with the "complicated" part, but not the "over" part.


|> 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.

Ones I might write. How would yours allow the application to verify
the trust chain?


|> 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.

Yours looked way too simple to me to deal with the many things I know that
security applications may need. Not all applications are going to be numb
about the kind of security they get with a connection.


|> 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.

Weak ciphers are a reasonable compromise between computer CPU power
needed and speed. For example, transmission of a video stream would
be a high bandwidth and not needing the kind of security used by
intelligence traffic between government agencies like NSA (who are
probably using something way more complicated and know how to handle
it).


|> 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.

You want the library to read separate configuration files instead of
the application to read integrated configuration files? What if the
configuration needs to be in an SQL database?


|> 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.

I have done a little bit of OpenSSL interfacing. I feel that while it is
a complicated API, it is a "just right" level of complexity.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-19-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

On Sun, 19 Aug 2007 08:33:02 -0000 Harold Weissman <(E-Mail Removed)> wrote:

| The specialized literature has made similar criticisms of the
| OpenSSL API. This API is the most widely used not because it is the best
| around, but despite of the fact that it isn't.

I believe OpenSSL is GPL licensed. That means you would be able to make
use of the code developments of OpenSSL to speed up the developement of
SimpleHWSSL. You think you could have it done in by the end of the year?
If a simpler API is indeed what people want, it should be popular and you
may even get a corporate sponsor. Go ahead and open a SourceForge project
and you may even get others wanting to join in and help.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-19-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

On Mon, 20 Aug 2007 01:36:07 +0000, phil-news-nospam wrote:

> On Sat, 18 Aug 2007 20:51:30 -0000 Harold Weissman
> <(E-Mail Removed)> wrote:
>
> | 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.
>
> The application may need to set parameters. And it may need to provide
> the certificates, or check that of the peer, rather than just assume the
> generic choices in a transparent library would suffice.

These two features are trivially done in a properly desgined
context. More importantly, they do not require any intervention byt the
application programmer at the protocol level - which is something that
OpenSSL forces one to do all too often.

> One application
> might need everything to be different than another application. This is
> one reason quite a number of facilities should be available.

This is another meaningless generalization. Please give examples
that justify the need of an API as complex as OpenSSL's.

>
> |> 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.
>
> I don't see it as "over complicated". I see it as "very complicated" in
> proprtion to the details that need to be dealt with by the application.
>
> So, basically, I agree with the "complicated" part, but not the "over"
> part.

OK, we disagree.

> |> 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.
>
> Ones I might write. How would yours allow the application to verify the
> trust chain?

The verification of a trust chain must be done internally by the
library. All the necessary public keys can (should) be made available to
the code at run time; that's indeed the way it already works with
OpenSSL. Again, as an application programmer, I don't care how that
verification is carried out; it's the librarie's job.

>
> |> 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.
>
> Yours looked way too simple to me to deal with the many things I know
> that security applications may need. Not all applications are going to
> be numb about the kind of security they get with a connection.

OK. Describing explicit cases in which the super-simple API would
not cut it would be extremely useful. Please go ahead.


> |> 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.
>
> Weak ciphers are a reasonable compromise between computer CPU power
> needed and speed. For example, transmission of a video stream would be
> a high bandwidth and not needing the kind of security used by
> intelligence traffic between government agencies like NSA (who are
> probably using something way more complicated and know how to handle
> it).

First, what do you call a weak cipher? 40-bit DES? Well, fine
tuned AES-128 software implementations are much faster than this cipher,
and I would be surprised if they are more CPU intensive. 40-bit DES is
almost trivially broken - if you want something weaker than that, you
might just as well use no encryption at all.

Video streams: What kind? I would have thought that the Hollywood
people would want something as strong as possible for their video
streams. What kind of video is it that you have in mind that could do
with weak encryption, but not without any encryption at all?

> |> 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.
>
> You want the library to read separate configuration files instead of the
> application to read integrated configuration files? What if the
> configuration needs to be in an SQL database?

Why would it need to be in an SQL database? Do you have any
examples? Also, OpenSSL already reads configuration files.

> |> 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.
>
> I have done a little bit of OpenSSL interfacing. I feel that while it
> is a complicated API, it is a "just right" level of complexity.

Well, so have I, and I feel it is overcomplicated. Even worse: I
have participated on efforts to port it to embedded environments with non-
socket oriented interfaces, and the performance of the resulting code was
so pitiful that it had to be ditched altogether. Maybe it just was my
personal incompetence, but we are talking two separate teams, with
different people. Well, maybe we were all incompetent. Or maybe not.