[Coco] Tcp off-loading on CoCo

[Christopher Noyes]

Not sure about TLS but SSL requires about 128k per connection.  I'm pretty sure no 8bit CPU is going to be capable of such a connection.

Sent from my iPhone

> On Apr 12, 2017, at 13:51, Mark D. Overholser <marko555.os2 at gmail.com> wrote:
> 
>> On 09-Apr-17 09:51, William Astle wrote:
>>> On 2017-04-09 09:53 AM, Brett Gordon wrote:
>>> Modern internet pretty much will require TLS and oauth for the coco to do
>>> anything internet related (twitter,gmail,fb,  etc.).   This would seem to
>>> make tcp offloaders like wiznet, or esp8266 less desirable?  I'm finding
>>> plain tcp has limitations:  many inet services pretty much require a
>>> secure
>>> and authenticated connection.
>> 
>> TLS is the big thing that's actually needed to access many extant
>> internet services. It is not, however, a network stack protocol (believe
>> it or not). It operates *above* TCP, and sometimes even above an
>> additional application layer. That means a TCP offloader is still useful
>> since it takes the work of dealing with the actual TCP protocol off the
>> Coco, and that's nothing to sneeze at. Whether that offload is handled
>> by a hardware device with esp8266 or something like Drivewire, it's
>> still beneficial.
>> 
> 
> I concur....   Do you have any idea how much RAM is needed to Calculate TLS, or how big the Code would need to be??
> 
> 
>> TLS is not required for things we develop ourselves for the Coco. That
>> is, if you're making a server side application on Fuzix, say, you don't
>> have to worry about all that. The application maker gets to choose
>> whether the encryption junk is required, or whether fancy things like
>> OAUTH are.
>> 
> 
> I concur....    Only the Server enforces the Security, ( or Doesn't )...  The intermediate Switches and Networks don't care....
> 
>> Thus, TLS is mostly required for client-side operations reaching public
>> services. How many of us are going to use web browsers running on the
>> Coco, realistically? Probably not many. It's really something of a
>> whistling dog situation. (And, the javascript and graphical requirements
>> to use many of those sites are pretty heavy anyway.) The same goes for
>> email access using POP3/IMAP/SMTP.
>> 
> 
> There are bound to be Simple Sites that won't have a large burden, but those sites probably won't require TLS and SSL...
> 
> 
>> Still, here's my take on doing that if we want:
>> 
>> TLS is an application layer protocol. As far as TCP is concerned, it's
>> just the connection payload. The client and server applications are the
>> ones that decode it. It happens entirely in userspace modulo any crypto
>> accelerators that might be in use.
>> 
>> Presumably, the Coco could be taught to do TLS if the memory
>> requirements are not too high. Obviously that wouldn't be using a
>> library like OpenSSL or GNU TLS or the like since those are likely far
>> too big. It would have to be far more focused so it didn't overflow the
>> available resources on the Coco. (Say by only implementing a current
>> version of TLS and ignoring all the old junk, and only implementing a
>> selection of ciphers.) If that is even possible. I can see how this
>> would probably best be done in a way that allows for an offload of the
>> TLS operations to a device of some kind (or at least to a separate
>> process). (Usually, TLS libraries work as a shim between the real
>> communication channel and the application anyway so that's likely not so
>> difficult.) The thing to remember is that not every connection that uses
>> TLS immediately starts up using it. It can be added later in some
>> protocol specific way in many cases (notably SMTP and IMAP support this,
>> but there's even a way in HTTP).
>> 
> 
> This really might need to be done with a Different System, like a Proxy Server that Bridges between Secure and Non-secure systems...
> 
> On the Idea of limiting the TLS Version and the Ciphers Supported, maybe making a menu for each, so if you only "Load" the TLS Version and a Cipher you know will work for each connection...
> 
> Going back to the modified Proxy Server, it could also be purposed to report, ( like a DNS Server ) for a Given Site what is the Smallest ( resource wise ) TLS and Cipher that can be used to Access It..
> 
>> Once TLS is cracked, though, absolutely everything else is definitely
>> application layer. OAUTH is built on top of the web browser and works
>> using HTTP redirects and a server<->server exchange in the background.
>> The client side doesn't need anything beyond a functional browser that
>> supports redirections, HTTPS, and probably cookies. The server side is
>> heavier, but remember, if we're making the application, we can choose
>> not to require something like that.
>> 
> 
> Yes.....
> 
>> Basically, the point of this is that TCP offload is still a good idea.
>> If you can somehow offload the crypto stuff in a useful way (it can be
>> turned on and off mid-stream), too, that would likely also be helpful.
>> The crypto offload need not be the same device, though.
>> 
>> 
> 
> 
> Thank Goodness......
> 
> ( Says the guy interested in making Networked Games on older 8 Bit Computers )
> 
> MarkO
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco