Re: The OpenSSL API

On Mon, 20 Aug 2007 12:25:51 +0000, phil-news-nospam wrote:

On Mon, 20 Aug 2007 08:50:16 -0000 Harold Weissman
<HaroldW22@xxxxxxxxxxx> wrote: | On Mon, 20 Aug 2007 01:36:07 +0000,
phil-news-nospam wrote: |
|> On Sat, 18 Aug 2007 20:51:30 -0000 Harold Weissman |>
<HaroldW22@xxxxxxxxxxx> 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.

Are you saying that all applications must be forced to do things the way
one application finds is a minimal level of necessity?

No. I am saying that the OpenSSL API is too complicated. By
implication, I am saying that should be as simple as possible, but not
simpler.

Just because one
application does not need to handle its own security contexts, how does
that show that every application must be denied that ability by removing
such from the API?

It doesn't. Which is why I never said, or implied that.

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

If I were currently developing or maintaining such an application, maybe
I would give you that example. How about you give an example of the
steps used by your application (it seems you are currently doing that if
you are raising this issue right now) plus an illustration of what you
think would be a simpler set of steps for comparison?

I already said so: I want to establish a secure channel with a
remote party (first call; the library would take care of all the nitt-
gritty details having to do with key exchange mechanisms, ciphers and
authentication, with minimal input from me - e.g. whether, when acting as
a server, I would like for the client to authenticate itself.)

I want to exchange arbitrary data securely with that party
(second and third calls.) The interpretation of the data is of course
irrelevant to the SSL layer.

I want to be able to close the channel when I am done, with the
possibility of reopening it again without key material renegotiation
(fourth call.)

What else do I need? What are that applications that you have
developed that could not make do with this?

|> So, basically, I agree with the "complicated" part, but not the
"over" |> part.
|
| OK, we disagree.

Right. This whole thread seems to come down to opinion. But I still do
not see or understand what you think a simpler API could be like. Maybe
if you created a document proposing such an API I or we could go over it
and see if it can either replace the existing API or supplement it by
being a new layer over the existing API.

I have already described a very simple API. The idea is for
people to shoot holes in it, so that it can be beefed up accordingly. If
the OpenSSL API offers a balanced, optimal complexity levels, one should
soon reach a comparable level (on the large scale, not the details, of
course.) The fact that no one has pointed out any glaring holes is kind
of worrying.

Would it be acceptable to you for a supplementary API to be used over
the existing API, if one can be created?

Most definitely. Something that hides all the ugliness exposed by
OpenSSL would be most welcome. In principle, I couldn't care less about
what underlies such API, as long as it gets the job done for me.

If not, this would need a new library and I don't think very many
people would be interested in that.

In truth, most people would not switch to a new API, period.
Human inertia is a mighty force.

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

I'll need to see a complete API document to work from. But this is also
a time consuming task (to go through all possible SSL needs). I'm not
even working on any SSL using project at all right now, so I have
nothing to offer as a current example right now. Maybe someone else
does.

That's OK, I am not here to peddle a new API. I am much more
interested to find out why OpenSSL is so complicated. Maybe, just maybe,
there is no good theoretical or technical reason; maybe it is the
authors' bias/lack of thorough understanding/preferences, or maybe just
cruft accumulation from its many contributors. I don't know. I hope it is
not anything like that.

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

I'm sure a fine tuned X-bit cipher is faster than a similarly fine tined
3*X-bit cipher. It's all relative until a specific need exists.

If it is the same cipher, yes. If we are comparing different
ciphers, no. You can tune 40-bit DES software to death, but on most
platforms its performance will never come even close to fine-tuned
AES-128. Let me give you an example I happen to be familiar with.

I have used DES and AES implementations, both of them carefully
hand-coded in IA64 assembler, under Itanium 2 (which, whatever its other
demerits, is one hell of a processor for highly performant cryptographic
code development.) DES performed at some 30 cycles per byte, whereas AES
would do it at 9 cycles per byte (CBC mode in both cases.) Figures for
IA32 are less spectacular, but they still illustrate the point
unambiguously.

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

The video streams might be those from security cameras encrypted by
small and slow embedded CPUs. Hollywood has nothing to do with it.
Hollywood does not have exclusive control over things not their own.
Think more about all those cameras that are used on highways to monitor
traffic or in malls to monitor personal security. There are many many
more examples (but I won't waste my time providing them if you cannot
understand it by now).

OK, that's a good example. Still, it does not provide any support
to the idea of using a weaker cipher.

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

Some very large applications might have hundreds of millions of elements
of data to work with. While I personally could still implement such a
thing very successfully on plain files with a smart choice of filesystem
types (hint: not ext2), it is the case that almost all programmers use
some kind of relational or hierarchical database system. Don't assume
that because your application does not need an SQL database that no
others ever will.

That's fine, but it has nothing to with the issue in hand,
consisting of the complexity of OpenSSL. All those SQL-related would have
to be handled by the application, not by the SSL library. Although it is
true that it throws in everything plus the kitchen sink, out of the box
OpenSSL knows nothing about SQL. And rightly so.

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

I'll avoid commenting about any incompetence. I happen to find that
OpenSSL really is complicated to program around, too. Where we are in
disagreement is not the complexity, but rather, whether there is a need
for that complexity.

Correct. But I have given examples of what it is that I want to
with SSL, and how OpenSSL is vastly overcomplex for such purposes.
In return, what I would expect is for somebody to supply an example of an
SSL application that just could not be developed with a much simpler API,
like the one sketched.

This is of course a far easier undertaking than describing a set
of SSL applications that, overall, would require all the complexity of
OpenSSL, in turn something far easier than showing that no set of SSL
applications would require anything not provided by OpenSSL.

If you can make a simpler API, I'll consider it with my next SSL
project. If it can use it, great. If not, there's always the legacy
complicated API.

That's a pragmatic way of looking at things, which I will never
dispute. Sadly, it does not get us any closer to finding out why OpenSSL
makes it so difficult for developers.



.

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
    ... How does this justify the complexity of the OpenSSL API? ... OpenSSL is not the most secure facility, ...
    (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)
  • Re: On Open Source
    ... you could just as easily delete the public key from your other box (e.g. ... A too small API is difficult to work with for a trained professional, ... >> those things (not trained professionals, ... The point isn't that OpenSSL is flawed it is that security should ...
    (sci.crypt)