Support for HTTP/TLS/TCP

[mnm364]

Hey Maintainers!

Generally inquiring if there is a timeline/roadmap to support the HTTP/TLS/TCP components of the Golden Gate stack that are referenced in the documentation but not yet implemented? Furthermore, if you can comment, is this something that is slated to be externalized or would this project benefit from net-new contributions to those parts of the stack? Please advise.

Thanks!

[barbibulle]

We do have some work-in-progress branch for adding TCP sockets and TLS support for those sockets. Not sure yet exactly when those would be stable enough to share. I'll take a look. As far as HTTP, we haven't started that. I is likely that we'd want to just have socket-api adapters for an existing HTTP client library, because there are a bunch of good ones out there that would work well with the rest of the library. The key element for a choice would be to use one that uses an async/non-blocking parsing model, because that's what would work the best with the rest of the framework. If you know of good candidate HTTP libraries that work that way, I'd love to take a deeper look.

[mnm364]

Thanks for that information and context. I really appreciate your fast responses. Could you point to the branch in question? I took a look at those listed but none of them pop out as obvious candidates.

Also, if I may ask a follow-up.. in general what inspires the need to re-implement these protocols (HTTP, TLS) when we can take advantage of the implementations already included in respective platforms (iOS, Android)? Is this merely for cross-platform considerations or is there some performance consideration with being able to control the network stack in a more fine-grained manner?

[nilstk]

Just in case usual TLS/SSL is still open (I'm still reading the docu), I'd would be in favor of it as well.

@mnm364 I don't know their reasons, but I'm seeking an additional security layer, because Bluetooth is cracked. If you look for the KNOB attack in the scientific community, you will find information that the session key can be reduced to 1 byte (classic) and 7 bytes (LE) just by an attacker requesting it. That renders BT's encryption pretty much useless and we are required to add an additional encryption layer.

[nilstk]

@barbibulle is it possible to get access to your TCP/TLS solution with socket-api adapters maybe? Do you plan to release it any time soon?