Ada for the TLS/SSL problem?

Ada for the TLS/SSL problem?

[Peter Brooks]

There are still many problems turning up with TSL authentication. It's no particular surprise as even OpenSSL has been using C for this code.

Isn't this an opportunity for Ada to really shine? 

It's a really important problem - having secure, reliable communication to web servers is something most of the sane world needs urgently.

It plays to all Ada's strengths:

- It must be cross platform
- It is embedded code, no need for any GUI design
- It requires clear, open source, elegant code, that is not vulnerable to things like the buffer overrun that caused the heartbleed problem (beloved of Microsoft)
- It is a relatively small, well contained problem.

Are there any Ada programmers who'd be willing to take part in defining the requirements for the project, and, then, ideally, producing the code?

I've been thinking that it might make sense, when the project is properly defined, to apply for seed capital to fund the design, development, testing, and marketing. If that succeeded, then, with everybody funded for their time, it stands a better chance of being complete in good time.

Any thoughts?

Ada for the TLS/SSL problem?

[Shark8]

It is a place for Ada to shine, certainly --  I had started an implementation of TLS but was stymied when I came to the X.509 (IIRC [security certificates]) requirement.

I thin there was someone here on comp.lang.ada who was doing a SPARK implementation of ASN.1's OID which, IIRC, is used in X.509 -- so we might actually be closer than anyone really realizes.

Ada for the TLS/SSL problem?

[Shark8]

> Are there any Ada programmers who'd be willing to take part in defining the requirements for the project, and, then, ideally, producing the code?

I would be willing to do so -- I read the requirements some time ago and, IITRC, there were two big dependencies: X.509 and, transitivly, ASN.1's OID.

Re: Ada for the TLS/SSL problem?

[Peter Brooks]

On Tuesday, 15 March 2016 21:00:21 UTC+2, Shark8  wrote:
> It is a place for Ada to shine, certainly --  I had started an implementation of TLS but was stymied when I came to the X.509 (IIRC [security certificates]) requirement.
> 
> I thin there was someone here on comp.lang.ada who was doing a SPARK implementation of ASN.1's OID which, IIRC, is used in X.509 -- so we might actually be closer than anyone really realizes.

That sounds very good. 

Re: Ada for the TLS/SSL problem?

[Florian Weimer]

* Peter Brooks:

> There are still many problems turning up with TSL authentication. It's
> no particular surprise as even OpenSSL has been using C for this code.
>
> Isn't this an opportunity for Ada to really shine?

It's really hard to write a good TLS implementation.  Ditching C gets
rid of just one class of issues (related memory safety).  All the
cryptography problems remain mostly unchanged.  This concerns both
low-level issues (such as avoiding informnation leaks due to timing
and other mishaps) and high-level design issues in TLS itself.

Re: Ada for the TLS/SSL problem?

[Paul Rubin]

Peter Brooks <peter.h.m.brooks@gmail.com> writes:
> Isn't this an opportunity for Ada to really shine? 

Yes, I've been thinking about it for a while.

> - It is a relatively small, well contained problem.

I don't believe this, it is quite complicated.  But it's doable.

> Are there any Ada programmers who'd be willing to take part in
> defining the requirements for the project, and, then, ideally,
> producing the code?

Yes, I'm not much of an Ada programmer but I'm experienced with crypto
and SSL implementation, and an Ada TLS stack is something I've been
interested in.  I'd want to use Ada 2012 with as much formal
verification as is practical.  It seems to me that the Muen implementers
have been heading in that direction too.

> I've been thinking that it might make sense, when the project is
> properly defined, to apply for seed capital to fund the design,
> development, testing, and marketing. If that succeeded, then, with
> everybody funded for their time, it stands a better chance of being
> complete in good time.  Any thoughts?

If it's funded, count me in, I think I can help.

Re: Ada for the TLS/SSL problem?

[Peter Brooks]

On Tuesday, 15 March 2016 23:02:11 UTC+2, Paul Rubin  wrote:
> Peter Brooks <peter.h.m.brooks@gmail.com> writes:
> > Isn't this an opportunity for Ada to really shine? 
> 
> Yes, I've been thinking about it for a while.
> 
> > - It is a relatively small, well contained problem.
> 
> I don't believe this, it is quite complicated.  But it's doable.
>
I said 'small' and 'well contained' -- not easy!
> 
> > Are there any Ada programmers who'd be willing to take part in
> > defining the requirements for the project, and, then, ideally,
> > producing the code?
> 
> Yes, I'm not much of an Ada programmer but I'm experienced with crypto
> and SSL implementation, and an Ada TLS stack is something I've been
> interested in.  I'd want to use Ada 2012 with as much formal
> verification as is practical.  It seems to me that the Muen implementers
> have been heading in that direction too.
>
Excellent - maybe the time for the idea is here.
> 
> > I've been thinking that it might make sense, when the project is
> > properly defined, to apply for seed capital to fund the design,
> > development, testing, and marketing. If that succeeded, then, with
> > everybody funded for their time, it stands a better chance of being
> > complete in good time.  Any thoughts?
> 
> If it's funded, count me in, I think I can help.
>
Thank you - I'll see how it goes.

Re: Ada for the TLS/SSL problem?

[Paul Rubin]

Peter Brooks <peter.h.m.brooks@gmail.com> writes:
> Excellent - maybe the time for the idea is here.

I talked with some crypto people about it this evening and they were
supportive of the idea, though the general feeling these days is that
TLS sucks.

> > > to apply for seed capital to fund the design,
> > If it's funded, count me in, I think I can help.
> Thank you - I'll see how it goes.

I don't understand what the pitch for this would be for investors
wanting to turn a profit.  It might be better to approach potential
users or even the OpenSSL consortium or whatever they call it.

Re: Ada for the TLS/SSL problem?

[Dmitry A. Kazakov]

On 15/03/2016 21:47, Florian Weimer wrote:
> * Peter Brooks:
>
>> There are still many problems turning up with TSL authentication. It's
>> no particular surprise as even OpenSSL has been using C for this code.
>>
>> Isn't this an opportunity for Ada to really shine?
>
> It's really hard to write a good TLS implementation.  Ditching C gets
> rid of just one class of issues (related memory safety).

At least we could have a better API. GNUTLS design is quite 
uncomfortable to use in a "socket-select" environment.

> All the
> cryptography problems remain mostly unchanged.  This concerns both
> low-level issues (such as avoiding informnation leaks due to timing
> and other mishaps) and high-level design issues in TLS itself.

Yes

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for the TLS/SSL problem?

[Jacob Sparre Andersen]

Peter Brooks wrote:

> Are there any Ada programmers who'd be willing to take part in
> defining the requirements for the project, and, then, ideally,
> producing the code?

Yes.

> I've been thinking that it might make sense, when the project is
> properly defined, to apply for seed capital to fund the design,
> development, testing, and marketing. If that succeeded, then, with
> everybody funded for their time, it stands a better chance of being
> complete in good time.

I've been considering if one could apply for EU industrial research
funds for such a project.

Greetings,

Jacob
-- 
»I'm perfectly happy with my current delusional system.«
                                           -- Mirabel Tanner

Re: Ada for the TLS/SSL problem?

[Dmitry A. Kazakov]

On 16/03/2016 09:42, Jacob Sparre Andersen wrote:
> Peter Brooks wrote:
>
>> I've been thinking that it might make sense, when the project is
>> properly defined, to apply for seed capital to fund the design,
>> development, testing, and marketing. If that succeeded, then, with
>> everybody funded for their time, it stands a better chance of being
>> complete in good time.
>
> I've been considering if one could apply for EU industrial research
> funds for such a project.

Don't they fund only one third of the costs?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for the TLS/SSL problem?

[G.B.]

On 16.03.16 09:42, Jacob Sparre Andersen wrote:

> I've been considering if one could apply for EU industrial research
> funds for such a project.

Just looking around, for including in TLS, there is
http://www.secunet.com/en/das-unternehmen/presse/news/news/elliptic-curve-cryptography-made-in-germany/?cHash=9435472bc77cd48ce94da5c5f563bf7b

Re: Ada for the TLS/SSL problem?

[Peter Brooks]

On Wednesday, 16 March 2016 08:13:44 UTC+2, Paul Rubin  wrote:
> Peter Brooks <peter.h.m.brooks@gmail.com> writes:
> > Excellent - maybe the time for the idea is here.
> 
> I talked with some crypto people about it this evening and they were
> supportive of the idea, though the general feeling these days is that
> TLS sucks.
> 
Yes, both SSL and TLS have problems. The only reason for saying 'TLS' is to give an idea of the project.

My feeling is that we'd need a general, configurable, security layer. This can be proved to work by implementing TLS.

However, stage 2 would be to develop a better, Ada-based, security layer. That would mean also having an Ada plug-in for browsers. Then it would be possible to have a secure security layer.

Re: Ada for the TLS/SSL problem?

[Peter Brooks]

On Wednesday, 16 March 2016 10:42:24 UTC+2, Jacob Sparre Andersen  wrote:
> Peter Brooks wrote:
> 
> 
> I've been considering if one could apply for EU industrial research
> funds for such a project.
> 
That's a good idea - it does fit with their current requirements.

The pitch, such as it is, would be either:

- Supporting it as a grant or sponsor to be associated with the project
- Invest in the project. 
 - In this case there would need to be a two-level licensing model
   - free for end user organisations, or FOSS projects
   - a licence fee for anybody incorporating it into a commercial product

Re: Ada for the TLS/SSL problem?

[Bob Butler]

On 2016-03-16, Peter Brooks <peter.h.m.brooks@gmail.com> wrote:
> On Wednesday, 16 March 2016 10:42:24 UTC+2, Jacob Sparre Andersen  wrote:
>> Peter Brooks wrote:
>> 
>> 
>> I've been considering if one could apply for EU industrial research
>> funds for such a project.
>> 
> That's a good idea - it does fit with their current requirements.

Don't forget Adacore exists because of US government grants. GNAT was
developed with state and federal funding. Dewar was able to write code on
the government dole and turn it into the most successful Ada vendor. That
angle is worth pursuing again, SSL is a much bigger public benefit.

Bob

Re: Ada for the TLS/SSL problem?

[G.B.]

On 16.03.16 11:52, G.B. wrote:
> On 16.03.16 09:42, Jacob Sparre Andersen wrote:
>
>> I've been considering if one could apply for EU industrial research
>> funds for such a project.
>
> Just looking around, for including in TLS, there is
> http://www.secunet.com/en/das-unternehmen/presse/news/news/elliptic-curve-cryptography-made-in-germany/?cHash=9435472bc77cd48ce94da5c5f563bf7b
>
>

Some more, notice the institute and the project's sponsor:
https://www.sit.fraunhofer.de/en/volksverschluesselung/

Re: Ada for the TLS/SSL problem?

[Dmitry A. Kazakov]

On 2016-03-16 13:09, Peter Brooks wrote:

> My feeling is that we'd need a general, configurable, security
> layer.  This can be proved to work by implementing TLS.

Well from my POV the idea of a layer as known in SSL/TLS is a 
non-starter. It is broken per design because it cannot provide 
reasonable QoS, short latency required for automation and control 
applications.

The basic requirement is that encryption and signing may not coalesce 
transport packets. Ideally it should work on the packet level with 
packets of any length. I understand that this would impose difficult 
problems but otherwise it would be unusable outside lousy web applications.

It is OK to implement TLS as-is, nobody would object that. But something 
better must be really better.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for the TLS/SSL problem?

[Florian Weimer]

* Dmitry A. Kazakov:

> On 15/03/2016 21:47, Florian Weimer wrote:
>> * Peter Brooks:
>>
>>> There are still many problems turning up with TSL authentication. It's
>>> no particular surprise as even OpenSSL has been using C for this code.
>>>
>>> Isn't this an opportunity for Ada to really shine?
>>
>> It's really hard to write a good TLS implementation.  Ditching C gets
>> rid of just one class of issues (related memory safety).
>
> At least we could have a better API. GNUTLS design is quite
> uncomfortable to use in a "socket-select" environment.

That's a consequence of the protocol because any write or read at the
application layer can result in arbitrary sequences of reads *and*
writes on the socket layer.  There is just no nice way to express this
in an API.

Re: Ada for the TLS/SSL problem?

[Dmitry A. Kazakov]

On 2016-03-16 18:42, Florian Weimer wrote:
> * Dmitry A. Kazakov:
>
>> On 15/03/2016 21:47, Florian Weimer wrote:
>>> * Peter Brooks:
>>>
>>>> There are still many problems turning up with TSL authentication. It's
>>>> no particular surprise as even OpenSSL has been using C for this code.
>>>>
>>>> Isn't this an opportunity for Ada to really shine?
>>>
>>> It's really hard to write a good TLS implementation.  Ditching C gets
>>> rid of just one class of issues (related memory safety).
>>
>> At least we could have a better API. GNUTLS design is quite
>> uncomfortable to use in a "socket-select" environment.
>
> That's a consequence of the protocol because any write or read at the
> application layer can result in arbitrary sequences of reads *and*
> writes on the socket layer.  There is just no nice way to express this
> in an API.

It could have a state machine design, driven by write-ready read-ready 
events.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for the TLS/SSL problem?

[Peter Brooks]

On Wednesday, 16 March 2016 19:05:09 UTC+2, Dmitry A. Kazakov  wrote:
> On 2016-03-16 13:09, Peter Brooks wrote:
> 
> > My feeling is that we'd need a general, configurable, security
> > layer.  This can be proved to work by implementing TLS.
> 
> Well from my POV the idea of a layer as known in SSL/TLS is a 
> non-starter. It is broken per design because it cannot provide 
> reasonable QoS, short latency required for automation and control 
> applications.
> 
> The basic requirement is that encryption and signing may not coalesce 
> transport packets. Ideally it should work on the packet level with 
> packets of any length. I understand that this would impose difficult 
> problems but otherwise it would be unusable outside lousy web applications.
>
SSL, and TLS are defined at level 6 of the OSI model. See: https://en.wikipedia.org/w/index.php?title=OSI_model&action=submit
> 
> It is OK to implement TLS as-is, nobody would object that. But something 
> better must be really better.
> 
Undoubtably!

Re: Ada for the TLS/SSL problem?

[Olivier Henley]

On Wednesday, March 16, 2016 at 1:05:09 PM UTC-4, Dmitry A. Kazakov wrote:
> On 2016-03-16 13:09, Peter Brooks wrote:
> 
> > My feeling is that we'd need a general, configurable, security
> > layer.  This can be proved to work by implementing TLS.
> 
> Well from my POV the idea of a layer as known in SSL/TLS is a 
> non-starter. It is broken per design because it cannot provide 
> reasonable QoS, short latency required for automation and control 
> applications.
> 
> The basic requirement is that encryption and signing may not coalesce 
> transport packets. Ideally it should work on the packet level with 
> packets of any length. I understand that this would impose difficult 
> problems but otherwise it would be unusable outside lousy web applications.
> 
> It is OK to implement TLS as-is, nobody would object that. But something 
> better must be really better.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Not sure but I think its related ... http://www.tcpcrypt.org/:

How Tcpcrypt is different

Some of us already encrypt some network traffic using SSL (e.g., HTTPS) or VPNs. Those solutions are inadequate for ubiquitous encryption. For example, almost all solutions rely on a PKI to stop man-in-the-middle attacks, which for ubiquitous deployment would mean that all Internet users would have to get verified by a CA like Verisign and have to spend money to buy a certificate. Tcpcrypt abstracts away authentication, allowing any mechanism to be used, whether PKI, passwords, or something else.

Next, Tcpcrypt can be incrementally deployed: it has a mechanism for probing support and can gracefully fall back to TCP. It also requires no configuration (try that with a VPN!) and has no NAT issues. Finally, Tcpcrypt has very high performance (up to 25x faster than SSL), making it feasible for high volume servers to enable encryption on all connections. While weaker by default, Tcpcrypt is more realistic for universal deployment.

We can easily make the bar much higher for attackers, so let's do it. How much longer are we going to stay clear-text by default?

Re: Ada for the TLS/SSL problem?

[Dmitry A. Kazakov]

On 2016-03-16 19:31, Peter Brooks wrote:
> On Wednesday, 16 March 2016 19:05:09 UTC+2, Dmitry A. Kazakov  wrote:
>> On 2016-03-16 13:09, Peter Brooks wrote:
>>
>>> My feeling is that we'd need a general, configurable, security
>>> layer.  This can be proved to work by implementing TLS.
>>
>> Well from my POV the idea of a layer as known in SSL/TLS is a
>> non-starter. It is broken per design because it cannot provide
>> reasonable QoS, short latency required for automation and control
>> applications.
>>
>> The basic requirement is that encryption and signing may not coalesce
>> transport packets. Ideally it should work on the packet level with
>> packets of any length. I understand that this would impose difficult
>> problems but otherwise it would be unusable outside lousy web applications.
>>
> SSL, and TLS are defined at level 6 of the OSI model. See: https://en.wikipedia.org/w/index.php?title=OSI_model&action=submit

Yes, and that is the problem. It is way too high, a typical abstraction 
inversion with a heavy burden on both communication and 
application/user. The latter simple cannot be responsible for 
authentication and signing.

If you want a security layer the level 6 is inappropriate for most use 
cases.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for the TLS/SSL problem?

[Florian Weimer]

* Dmitry A. Kazakov:

> On 2016-03-16 18:42, Florian Weimer wrote:
>> * Dmitry A. Kazakov:
>>
>>> On 15/03/2016 21:47, Florian Weimer wrote:
>>>> * Peter Brooks:
>>>>
>>>>> There are still many problems turning up with TSL authentication. It's
>>>>> no particular surprise as even OpenSSL has been using C for this code.
>>>>>
>>>>> Isn't this an opportunity for Ada to really shine?
>>>>
>>>> It's really hard to write a good TLS implementation.  Ditching C gets
>>>> rid of just one class of issues (related memory safety).
>>>
>>> At least we could have a better API. GNUTLS design is quite
>>> uncomfortable to use in a "socket-select" environment.
>>
>> That's a consequence of the protocol because any write or read at the
>> application layer can result in arbitrary sequences of reads *and*
>> writes on the socket layer.  There is just no nice way to express this
>> in an API.
>
> It could have a state machine design, driven by write-ready read-ready
> events.

It's still very complicated, particularly if you want to leave buffer
management to the caller.  See Java's SSLEngine.

Re: Ada for the TLS/SSL problem?

[Dmitry A. Kazakov]

On 16/03/2016 23:18, Florian Weimer wrote:
> * Dmitry A. Kazakov:
>
>> On 2016-03-16 18:42, Florian Weimer wrote:
>>> * Dmitry A. Kazakov:
>>>
>>>> On 15/03/2016 21:47, Florian Weimer wrote:
>>>>> * Peter Brooks:
>>>>>
>>>>>> There are still many problems turning up with TSL authentication. It's
>>>>>> no particular surprise as even OpenSSL has been using C for this code.
>>>>>>
>>>>>> Isn't this an opportunity for Ada to really shine?
>>>>>
>>>>> It's really hard to write a good TLS implementation.  Ditching C gets
>>>>> rid of just one class of issues (related memory safety).
>>>>
>>>> At least we could have a better API. GNUTLS design is quite
>>>> uncomfortable to use in a "socket-select" environment.
>>>
>>> That's a consequence of the protocol because any write or read at the
>>> application layer can result in arbitrary sequences of reads *and*
>>> writes on the socket layer.  There is just no nice way to express this
>>> in an API.
>>
>> It could have a state machine design, driven by write-ready read-ready
>> events.
>
> It's still very complicated, particularly if you want to leave buffer
> management to the caller.  See Java's SSLEngine.

Yes it is more complicated, but not for the user, who within this 
framework should already provide and consume data on demand. [It would 
be nice to have co-routine "tasks" in Ada to inverse that, but this is 
another story.]

Regarding buffer management, firstly you should need none, provided the 
design were indeed event-driven.

Secondly, for security reasons you probably would not want to have any 
external buffers anyway.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada for the TLS/SSL problem?

[Peter Brooks]

I've put together a brief (very brief) proposal for discussion here:

http://ow.ly/4n6pcl

It's more to identify and collect together interested parties than anything else. It's also a good place to suggest problems or improvements to the proposal.