[Coco] Tcp off-loading on CoCo

[Mark D. Overholser]

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