We've got a setup, where SSL/HTTPS stuff is managed by Cloudflare.
What is the proper way to run Node.js HTTPS server in this case?
I've tried running it like this and it's working, but what are the downsides?
const app = express()
const httpsServer = https.createServer({}, app) //creating https server with an empty ssl certificate object
httpsServer.listen(443)
I've tried running it like this and it's working,
By this, I assume you're using Flexible mode?
When in Flexible mode, it gives you the illusion of security, but in actuality
client-server connection is only half-secured.
Cloudflare Universal SSL Certiticate
|
Client <----HTTPS-----> Cloudflare <------HTTP-----> Origin Server
Surely you've heard of MITM (man-in-the-middle) attacks or state-sponsored surveillance over insecure channel (read: HTTP)? These are the downsides when your connection is not fully encrypted end-to-end.
For you to secure the connection end-to-end, you'll need to use Full/Full(Strict) mode, and for this to work you'll need to specify the certificate on the origin server. Opening port 443 and put it on listening mode is not enough, HTTPS uses Public Key Infrastructure (PKI) and SSL certificates are fundamental part of it. In other words, you simply can't use HTTPS without SSL certificates in place!
Cloudflare Universal SSL Certiticate Origin Certificate
| |
Client <----HTTPS-----> Cloudflare <------HTTPS-----> Origin Server
Provisioning a self-signed certificate on the origin server will suffice for Full mode, but Full(Strict) mode requires a valid certificate. Good new is that you don't need to purchase Extended Validation (EV) certificates from retail Certificate Authority (CA), as nowadays there are free Domain Validation (DV) certificates such as Let's Encrypt/Certbot or Cloudflare Origin CA certificate which would work just as fine.
Related
If I use a SSL certificate for an API deployed to my own IIS server, it will protect my network, my ports, or only the data of the requests?
SSL/TLS certificates are a means of authentication. The certificat authority where you register your certificate (e.g. LetsEncrypt) will vouch that you indeed own the domain you are trying to register a certifiate for. These certificates are then used to bootstrap an encrypted TLS connection between the users of your server and your server. Subsequent data transfer is then encrypted (I assume this is what you meant by 'protected'?).
I am not sure what you mean by 'protecting' your network or port. Could you elaborate on that?
SSL is digital certificate provide authentication/authorization for a webapp/website for data and help to share information or "data" in Internet encrypted.
If you want protect a network, DMZ or demilitarized zone implementation helps you in Internet world.
When you apply SSL certificate and https for your web api in IIS. SSL handshake will be applied before the connection. So it will create a security channel to enhance the connection and avoid man-in-the-middle attack. At the same time, all the data are transmitted under encryption. So hacker won't be able to see th clear context because they don't have key to decrypt the information.
In a word, SSL secure connection and data not network. IIS client certificate can also be used to authenticate user identity.
I am trying to set the client to nodes SSL encryption for one of our client.
I have confusion regarding the functionality of setting require_client_auth in client_encryption_options in cassandra.yaml and what configuration needs to set from client and cassandra node in case I set require_client_auth to true.
Password authentication is already set,now investigating if there might be any additional advantage to having both ("authenticator: PasswordAuthenticator" and "require_client_auth: true") turned on
As Jim stated, require_client_auth doesn't have anything to do with Cassandra's auth system. It is an additional level of security configuration for client-to-node SSL.
When you implement client-to-node SSL and enable require_client_auth you are enabling what is known as Two Way SSL. Instead of the Cassandra client simply verifying the identity of the server, the server also verifies the certificate used by the client. This doc One Way and Two Way SSL and TLS (Peeples K. 2015) has a good description of this process:
Two-way SSL authentication is also referred to as client or mutual authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.
Establishing the encrypted channel using certificate-based 2-Way SSL involves:
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
On the other hand, with One Way SSL the client only verifies the server's certificate (from the same doc).
The advantage of Two Way SSL would be in knowing that the Cassandra nodes will not allow a connection from an unknown client certificate.
IMO, one Way SSL still offers a decent degree of security. The dev team will need to present a cert which validates up through the same CA (certificate authority) as the cert from the Cassandra nodes. Two Way SSL might be useful in a large org, helping to keep out connections from applications that have not first talked with your team.
I believe the require_client_auth is for SSL (certificate) communication between the client and server, and that the client must identify itself (you can have it so that the server is the only one that identifies itself).
I have this web app that is served via https, and now it needs to use a websocket service that is served from another server. Chrome, Firefox and Internet Explorer complain right away that if the application is secure (https), then it is not allowed to connect to an insecure websocket service (ws:// URI). Strangely, Apple Safari doesn't complain so.
Well, fair enough, I assumed any globally trusted certificate would be fine to be installed at the websocket server side, to enable secure service (wss:// URI). However the company that maintains the socket server claims that they have to install there the very same certificate that secures my web application. I read in webs that the wss will not run with self-signed certificate, but nowhere that it must be the same certificate that the calling web site runs on.
Since we are talking sharing a certificate key file with 3rd party, I wanted to double check this. If my secure site runs at domain first.com, and the websocket server at IP address a.b.c.d, what kind of certificate should be installed on the websocket server to enable the communication? On one hand, that would be a kind of cross-site scripting, but perhaps the browser security model allows it, assuming the user knows what they want?
What I understand from above, the browser connects to your web application and is then redirected to the other server. If that be the case, then browser would complain about being redirected to unsecured site from a secured URL. The way forward actually depends on the domain of the server that the redirect is happening to, for example, if your main site has URL form www.mainsite.com and the target site has URL form abc.secondsite.com or an IP, the second server must have configured an SSL certificate that has been issued to either abc.secondsite.com of the IP i.e. the name of the host requested must match exactly with the SSL ceritficate that is provided by the secondsite.
The secondsite technically does not have to have the same certificate as your mainsite, it just have to be a certificate issued by a trusted source (like Verisign etc.).
On the other hand, if you have a wildcard subdomain certificate i.e. a certificate issues is valid for all the *.mainsite.com domains and the URL form of the secondsite is sub_domain.mainsite.com, then the same certificate can be used on both the servers.
Hope this helps.
thanks
Since we are talking sharing a certificate key file with 3rd party, I
wanted to double check this. If my secure site runs at domain
first.com, and the websocket server at IP address a.b.c.d, what kind
of certificate should be installed on the websocket server to enable
the communication? On one hand, that would be a kind of cross-site
scripting, but perhaps the browser security model allows it, assuming
the user knows what they want?
You cannot provide a certificate for an IP address. In order to use WSS:// you need to connect to a domain name, and have a valid certificate for that domain name. So you need a SSL certificate for the domain name of your WebSocket server.
As far as I know, it does not need to be the same than the one on the site. You can check by entering here: http://vtortola.github.io/ng-terminal-emulator/ and executing the command websocket wss://echo.websocket.org, you will connect to a WebSocket in websocket.org that echoes your inputs.
WebSockets are not constrained by the SOP (Same Origin Policy), you can connect anywhere, and the server is responsible of checking the HTTP request header "Origin" and accept or refuse the connection.
In IIS 7, I've created an https binding for a site, and I'd like to require client certificates for https and still keep my http endpoint.
That is to say, I'd like to require client certificates for my https endpoint without requiring SSL across the board and disallowing access to my http endpoint (via "require SSL" in SSL Settings). Is this possible?
Client certs are usually used for 2-way SSL, so not just the server but the client is also encrypting the traffic with it's private key.
If you don't want to enforce https across the board, then the one thing you can try is to accept the client cert ( see SSL settings ) then implement the cert validation in your application.
See Request.ClientCertificate on MSDN for more details
if (HttpContext.Current.Request.IsSecureConnection)
{
// it's SSL, so check the client cert
bool authorized = IsClientCertAuthorized(HttpContext.Current.Request.ClientCertificate)
}
Then implement that method as needed.
Note: I haven't tested this, so please comment if you've tried.
I have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.