Re: The OpenSSL API

On Mon, 20 Aug 2007 13:27:35 -0000 Harold Weissman <HaroldW22@xxxxxxxxxxx> wrote:
| 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.

Computers are complicated. The cause of this appears to be that different
people want to do different things and/or do things in different ways.
Complexity exists from flexibility. I think that is the case with OpenSSL.


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

So write a wrapper around OpenSSL so you only have to deal with all that
complexity one time.


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

True.


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

That doesn't seem like something that would be safe and secure.


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

Applications that control what ciphers to use, what certificates to
use, who to trust and not trust, special I/O blocking for speed, etc.


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

Please describe an API in terms of how an API is normally described.
List the functions available (their names) along with the arguments
for each, in detail (like if a struct is passed, all the members of the
struct), and the return values. Also any shared variables need to be
listed. Give enough info that if someone decides to, they can implement
this API exactly as expected.


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

You need a wrapper. I don't know if such a thing has ever been done.
Maybe it has.


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

Most people just avoid OpenSSL. Maybe that's a good thing.


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

If you are asking why it needs to have complexity, the answer that was
given is that crypto is complex, especially in all the various forms so
many different people want to use. If you are asking why there is no
wrapper that makes things simple for the majority subset of uses, that
I cannot answer other than to say that someone who wants everything to
be simple isn't likely the one to do it. But neither is one who feels
the need to use so much of the complex API.


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

There's more to do with AES. Is AES designed around the Itanium's
instruction set or something?


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

Well, I think it does, unless you can convince me that AES really is
faster than the fastest of weaker ciphers.


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

I know I certainly do not want OpenSSL doing SQL.


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

I didn't have any trouble imagining such an application when I browsed
through the OpenSSL API. I didn't imagine such much that I personally
would use.


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

I don't think any _one_ application would ever require the whole API.
The full set of all applications, though, could hist nearly all of it.


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

All I can say is that I do understand why OpenSSL is complex.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-22-1327@xxxxxxxx |
|------------------------------------/-------------------------------------|
.

Relevant Pages

  • Re: The OpenSSL API
    ... exchange | |> mechanism) and of the second by means of the certificates ... I am saying that the OpenSSL API is too complicated. ... 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)