Should kaa baseurl connection be ssl enabled eg. https://myurl.it/, so all communication over ports 9888, 9889, 9997 and 9999 are ssl encrypted?
Or is this builtin in the aka stack - so communication can be over http?
Kaa provides 2 default kinds of transport that cover data exchange needs of all the Kaa cluster services based on HTTP 1.1 and TCP. See Default transports documentation page at outdated documentation.
For other cases use this Kaa documentation.
Related
I have a Gateway API that is built with Golang. We use the "net/http" library documented here https://pkg.go.dev/net/http#example-ListenAndServeTLS. This service has HTTPS connection set up. The connections to my ELB’s use HTTPS because I use TLS termination. So this one Gateway API has the ssl cert. But then passes the connection to a regular HTTP connection to the other instances.
In short, the Gateway API has HTTPs support, but the services connected to my Gateway API uses HTTP.
When I check my UI services, It shows that we are using HTTP 1.1 still. However from Golang's documentation the package "net/http" should provide HTTP 2.0 support automatically.
Do I need to upgrade my internal services to use HTTPs instead of HTTP in order to use http 2.0?
Sorry If this post comes off as ignorant or rude. I really appreciate anyone taking there time to read this, and am willing to provide any more information that Is needed.
http2 include h2(TLS) h2c(no TLS), net/http use h2 default when ListenAndServeTLS.
if you use http, net/http not use h2c, but http1.1 currently no browser supports HTTP/2 unencrypted
becase net/http don't support h2c default, if you want use h2c(non-TLS version of HTTP/2):
https://pkg.go.dev/golang.org/x/net#v0.0.0-20220421235706-1d1ef9303861/http2/h2c
I know there are a lot of different comminucation protocals like: http, tcp, ssh, socks5, SMTP, POP,etc.
I also know that to achieve a comminication, we need to connect localhost:localport to remotehost:remoteport. For example, if we google something, we would connect a random local port to www.google.com: 80. If we ssh a remote host, we would connect a random local port to remotehost: 22.
My question is: Are communication protocol Half-duplex or Full-duplex?
I guess the answer is Half-duplex. Because I think in http connection, at first we send the request from localhost:localport to remotehost:80, and then the remote server send its response from remotehost:80 to localhost:localport. Similarly, in ssh connection, at first we sent the ssh commands to remote host, after receiving the commands, the remote host do something and send the results back to the local host.
So I think in one connection between localhost:localport and remotehost:remoteport, the message is sent either from localhost:localport to remotehost:remoteport, or from remotehost:remoteport to localhost:localport.
Am I right?
As explained in this article:
SSH is a bidirectional full duplex protocol, which means that it’s not synchronous like HTTP where you need to send a message for a response to happen.
With SSH the remote host might want to tell you something even if you have remained silent. This connector uses a callback flow approach to decouple the “sending” operation from the “receiving” operation.
As documented in this IETF draft, most implementations do allow full-duplex HTTP (for 2xx responses).
Full-duplex HTTP follows the basic HTTP request-response semantics but also allows the server to send response body to the client at the same time when the client is transmitting request body to the server.
Requirements for full-duplex HTTP are under-specified in the existing HTTP (Hypertext Transfer Protocol -- HTTP/1.1) specification, and this memo intends to clarify the requirements of full-duplex HTTP on top of the basic HTTP protocol semantics.
I've seen that some app developed in Go run without tls enabled from the app, rather enabled in its proxy server(nginx). The requests coming to the app is encrypted at the nginx side only. So the Go http server is served using only http.ListenAndServe.
While using gRPC, I've seen the gRPC server served without tls enabled, and the client dial with insecure mode enabled.
I assumed all of this because you only need enable tls only if you serve requests coming from outside(external networks). If you use http and grpc for internal services communication within internal network in microservices architecture, you don't need enable tls at all since it only adds overhead. Is this true?
How is tls properly applied in Golang development for http and gRPC server?
I'm newbie of grpc and have played with simple grpc clients of java, go, and python. I know basic http and https but not familiar with protocal details. So this question may be rediculous to you but I didn't find any explaination online.
I know grpc has insecure(go: grpc.WithInsecure(), python: grpc.insecure_channel, java: usePlaintext()) and secure mode(TLS). and grpc is based on httpv2, and http has security mode(https).
So what if use insecure grpc with https? Is the overall data transfer safe?
And what if use TLS grpc with https? Is there performance overhead(becuase I think the messages are encrypted twice)?
Thank you for any answer, any exsiting webpages explaining such topic that will be best!
Insecure implies http. And TLS implies https. So there's no way "to use insecure grpc with https", as at that point it is then http.
There is no double-encryption. The gRPC security mode is the same as the HTTP security mode.
Using gRPC over TLS is highly recommended if you gRPC server is serving requests coming from outside(external network). For example you're creating front end app in javascript serving user requests. Your javascript app make call to your gRPC server for APIs your server provide. Your javascript communicate to your gRPC server through stub created in javascript end. At the end of your gRPC server, you need to set tls mechanism to secure communication between your javascript app and your gRPC server(because requests coming from outside).
gRPC somehow mostly used for internal services communication inside internal network in microservice architecture. You don't need to set tls for internal network usage since requests coming from your own environment from within your watch.
If you want to apply something like "gRPC over HTTPS", then you need something like gateway to map your http call to your gRPC server. Check this out.
You need to compile your proto file as gateway service definitions as well using provided tools. Now you can create your normal http server with tls enabled through something like http.ListenAndServeTLS(...). Dont forget to register your grpc server to the http server using the service definitions compiled from the proto file. With this all your requests to are encrypted with tls to your http server like normal rest apis do, but get proxied to gRPC server you defined. There's no need to enable tls at your gRPC server since it has been enabled in your http server.
Is that possible to create Full-duplex persistent Http connection through 80-port with nginx which proxies requests to other internal servers? It has to be done to implement bidirectional binary data streaming between desktop applications through 80 port of the Http server.
You probably need some kind of HTTP tunnelling, or implement XMPP over HTTP in your application.