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.
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).
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.
We are evaluating feasibility of the following solution for Single Sign On.
Scenario.
Website domain. https://www.example.com
[SSL using multi-server wildcard certificate]
Hosted on Server 1.
Other portal. https://portal.example.com
[SSL using the same certificate (multi-server wildcard certificate)]
Hosted on Server 2.
Solution:
The intention is to share a cookie between the www.example.com and the portal.example.com subdomains, however, for this to work the SSL protocol needs to satisfy the following requirements:
Continue to block Man-in-the-middle attacks.
Encrypt/Decrypt in the same manner for both Server 1 and Server 2. So that they can get the same information from the cookie.
Question is: Is there any limitations in terms of private keys or the SSL protocol perse that will make the solution above not feasible?
Thanks,
Yes, your solution will work and will mitigate most MITM attacks provided the CA that your certificates are purchased from are trusted by the client browsers.
If the cookie is set with domain example.com it will be shared between www.example.com and portal.example.com. It is also advisable to set the Secure flag to make sure it cannot be transmitted over plain HTTP. I am assuming both www.example.com and portal.example.com both have a server-side mechanism to validate the cookie value to authorise each request.
RFC 6265 states:
The Domain attribute specifies those hosts to which the cookie will be
sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com.
The old RFC 2109 specified that you needed a . before the domain, however 6265 overrides this. This means if you want to share cookies and make it compatible with very old browsers you should set the cookie with domain .example.com rather than example.com. There is nothing to lose by doing the former as newer browsers will simply ignore the dot.
In your solution, both Server 1 and Server 2 will receive and be able to decrypt the cookie. Note there is not requirement for both servers to have the same certificate - they will both decrypt the SSL session independently using their installed private keys (or rather a shared symmetric key that is transmitted using their installed private keys - to be precise).
However, using a wildcard certificate for *.example.com will be cheaper as the same certificate can be installed on both servers.
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.