gRPC is based on http2 which must be use ssl.
But I found I can create use insecure server.
I want to know insecure means that don't use ssl or use predefined certificate for http2?
HTTP/2 does not insist on SSL/TLS. But all web browsers only implement HTTP2 over SSL/TLS because of problems when using it over plaintext HTTP over the Internet. So if not using a web browser but another HTTP/2 client than you can use HTTP/2 without SSL/TLS.
So yes insecure gRPC is using an unencrypted HTTP/2 connection (h2c). Though some implementations do not support this, similar to how web browsers do not support unencrypted HTTP/2 (h2c).
Related
new Cloudflare user here.
I have an A record, but I don't have the any cert installed on the server that I'm pointing to. I know you can proxy through CF and CF has free SSL set up on the proxy endpoint.
My question is: how does CF connect to my endpoint securely? Or am I understanding incorrectly?
My understanding:
me --[SSL-enabled]--> CF Proxy --[no SSL?]--> my server
The short answer is that CloudFlare doesn't connect to your endpoint securely through their free SSL certificate.
CloudFlare offers three types of SSL setups, with 'flexible' being the default:
Flexible: They'll serve content over HTTPS from their infrastructure, but the connection between them and the origin is unencrypted
Full: Still HTTPS from CloudFlare to the browser but they'll also talk HTTPS to the origin although they won't validate the certificate
Full (strict): CloudFlare issues the certificate and they'll intercept your traffic, but then it's all HTTPS to the origin and the cert is validated as well
While a flexible, free SSL certificate from CloudFlare will show your visitors a secure HTTPS padlock, this method of SSL only exists between CloudFlare and the ISP, not between CloudFlare and your server. The flexible certificate is shared between 50 different domains (revealing each of these to your visitors), though does indeed protect from common attacks such as WiFi snooping.
Flexible:
Full:
A Full certificate also encrypts traffic between CloudFlare and the origin, but CloudFlare doesn't validate the cert. A strict certificate remedies this.
If unsure on the quality of your SSL, I'd recommend checking out Qualys' SSL Labs test.
For more information see Troy Hunt's article on the issue.
how does CF connect to my endpoint securely?
Since you don't offer a secure connection to your endpoint Cloudflare cannot use a secure connection to your endpoint. This is, only the connection between the browser and Cloudflare is secure but not the final connection from Cloudflare to your server.
See also the description of the Flexible SSL option you are talking about which explicitly points of the problems:
Flexible SSL: A Secure connection between your visitor and Cloudflare, but no secure connection between Cloudflare and your web server. ... This option is not recommended if you have any sensitive information on your website. ...It should only be used as a last resort if you are not able to setup SSL on your own web server. ...
Currently, I have a ngnix server (on port 5001) behind which a gRPC server is running, nginx having TLS enabled. All gRPC clients need to send the request to nginx port which forwards to gRPC server running. Initially for testing had gRPC request using usePlaintext() and it all worked fine, but the end goal is to use TLS. The requirement here is (as this are internal applications), gRPC channel request need not pass certificate but do a "skip certificate" when creating the channel.
After Googling around, I found examples on TLS but all of them does take .cert, .key file. Below is snippet which i tried and it failed at the server end couldn't validate the certificate
(java code)
ManagedChannel channel = NettyChannelBuilder.forAddress(<server IP address>, 5001).sslContext(GrpcSslContexts.forClient().trustManager
(new File(<.cert file>).build())
.build();
Doing some more research, i see Golang has InsecureSkipVerify() using which i can skip ceritifcate check (pls correct me if i am wrong)
tc := credentials.NewTLS(&tls.Config{
InsecureSkipVerify: true,
})
Now how do I accomplish the same in java?
TLS with disabled certificate checking is of questionable usefulness because it can be trivially MITMed and so is not "supported" by gRPC. I highly recommend providing the client with proper root certificates to verify the server.
That said, you can go around gRPC's API to do this by passing Netty's InsecureTrustManagerFactory to SslContextBuilder.trustManager(TrustManagerFactory):
NettyChannelBuilder.forAddress("<server IP address>", 5001)
.sslContext(GrpcSslContexts.forClient()
.trustManager(InsecureTrustManagerFactory.INSTANCE)
.build())
.build();
https://www.playframework.com/documentation/2.3.1/ConfiguringHttps describes, in detail, how to implement SSL in Play Framework 2.3.x
However, I am wondering how to implement TLS 1.2 in Play Framework, do I also need something like Nginx?
I am fairly new to this subject. https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html shows us that SSL is older than TLS. I have heard that SSL is not secure any more, that's why I ask this question.
Nginx support TLS 1.2 without problems (check parameter "ssl_protocols"). Forget about SSL v2 and SSL v3, it is not secure, but most browsers support TLS v1.2, TLSv1.1 and TLS v1.
You can use Nginx as proxy, and configure HTTPS on nginx. Nginx has many usefull options, it can fast serving static files and proxying all other request to "play" application (to TCP port or to socket).
In your link there is information that you can run Play with HTTPS, so there is no need to use nginx, but I agreee with this part:
(..) using a reverse proxy in front of Play will give better control
and security of HTTPS.
Is it possible to have WebSockets with HTTPS?
When switching to HTTPS, my WebSocket returns a security error and works perfectly with regular HTTP.
Below, a snippet;
socket = new WebSocket("ws://my_www:1235");
The WebSocket connection starts its life with an HTTP or HTTPS handshake. When the page is accessed through HTTP, you can use WS or WSS (WebSocket secure: WS over TLS) . However, when your page is loaded through HTTPS, you can only use WSS - browsers don't allow to "downgrade" security.
You can't use WebSockets over HTTPS, but you can use WebSockets over TLS (HTTPS is HTTP over TLS). Just use "wss://" in the URI.
I believe recent version of Firefox won't let you use non-TLS WebSockets from an HTTPS page, but the reverse shouldn't be a problem.
1 additional caveat (besides the answer by kanaka/peter): if you use WSS, and the server certificate is not acceptable to the browser, you may not get any browser rendered dialog (like it happens for Web pages). This is because WebSockets is treated as a so-called "subresource", and certificate accept / security exception / whatever dialogs are not rendered for subresources.
To support the answer by #oberstet, if the cert is not trusted by the browser (for example you get a "this site is not secure, do you want to continue?") one solution is to open the browser options, navigate to the certificates settings and add the host and post that the websocket server is being served from to the certificate provider as an exception.
for example add 'example-wss-domain.org:6001' as an exception to 'Certificate Provider Ltd'.
In firefox, this can be done from 'about:preferences' and searching for 'Certificates'
Le'ts say you open a tcp socket on port 80 to handle http request, and a ssl socket on port 443 to deal with https...how can some proxy provide access to both of them on the same port??
I found only this link but it wasn't very useful. Can you provide me an erlang example or suggest me some resources from which i can learn more on the topic?
Thanks in advance
how can some proxy provide access to both of them on the same port??
By implementing the HTTP CONNECT method, the (non-transparent) proxy may switch to providing a TCP tunnel over which a browser may, for example, access an HTTPS resource.
A rather sparse specification:
https://www.rfc-editor.org/rfc/rfc2616#section-9.9
As outlined in the link you provide, you will need to write your own custom server that sniffs the request and then redirects to the correct protocol accordingly.
As http://www.faqs.org/rfcs/rfc2818.html indicates, an HTTP session will start with an Initial Request Line (e.g. GET /), whereas a TLS session will start with a ClientHello (more on the TLS session on wikipedia)
There are lots of resources online about writing servers in Erlang, e.g. How to write a simple webserver in Erlang?
Incidentally your terminology is incorrect: http, https SSL and TLS are protocols, and all operate (over the web) using TCP sockets.