Re: The OpenSSL API

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


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


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

Would it be acceptable to you for a supplementary API to be used over the
existing API, if one can be created? If not, this would need a new library
and I don't think very many people would be interested in 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.

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.


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


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


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


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

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.

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

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
    ... 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)
  • RE: Different credentials for remote registry/SCM access
    ... However, since these operations requires Admin right, you ... API with username/password of Admin to launch a Admin account's logon ... This API will return a security token which is a handle points to ... Microsoft Online Community Support ...
    (microsoft.public.platformsdk.security)
  • Re: SORTED
    ... Is it possible that this is in the "Security Center" API? ... This is demonstarated by the way a MS Windows security ... >> Application Integration Specialists ...
    (microsoft.public.win32.programmer.wmi)