I know something about how it work HTTP and HTTPS but there is something stuck in my head.
How is decrypt encrypted data?
Where is this decrypting? Is on OSI layers or Web servers?
My web server have 2 domain and two domains have SSL themselves
burak.com
omer.com
This is my vHost Conf file for "burak.com";
vhssl {
keyFile /etc/letsencrypt/live/www.burak.com/privkey.pem
certFile /etc/letsencrypt/live/www.burak.com/fullchain.pem
certChain 1
sslProtocol 30
}
When client sending "hello" message, who decide to "Which SSL Certificate will using for this connection?", Litespeed or Operating System (OSI) ?
If true answer is Litespeed, what is happening on "Presentation Layer" ?
Is this decrypting doing on "Application Layer"?
Related
I have configured my nginx to use the certificate and private_key that I downloaded from cloudflare crypto.
This is my nginx.conf file-
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name autocaptions.app *.autocaptions.app;
location / {
proxy_pass http://127.0.0.1:7887;
}
ssl on;
ssl_certificate /home/ubuntu/sslcerts/autocaptions.pem;
ssl_certificate_key /home/ubuntu/sslcerts/private-key.pem;
# ssl_client_certificate /home/ubuntu/sslcerts/cloudflare.crt;
# ssl_verify_client on;
}
# Redirect http to https
server {
listen 80;
listen [::]:80;
return 301 https://$host$request_uri;
}
I am not sure what the issue is. I have added the certificate and the private_key.
I see the following error in the browser when I try to access https://autocaptions.app -
Error in text-
autocaptions.app has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.
In Cloudflare configuration, I have disabled HSTS, not sure why this error is showing up.
I have followed digitalocean tutorial to configure SSL.
You are using a certificate signed by the "Cloudflare Origin CA". Certificates issued by this CA are intended to be installed on your origin server so that the communication between the Cloudflare CDN and your origin server can be protected by a certificate.
These kind of certificates are not intended on systems facing end users (i.e. browsers). They are only intended to secure the communication between your origin server and Cloudflare. Typical end users will not have the "Cloudflare Origin CA" as a trusted CA in their browser and thus they will get a TLS error when connecting to your origin server - and this is thus what you get. But typical end users should not connect to the origin server in the first place - they should connect to the Cloudflare instance instead. Only Cloudflare itself should connect to the origin server and they will acknowledge their own CA as trusted.
Check your site's SSL Setting under Crypto tab. Change it to 'Full' or 'Flexible' if its on 'Full (Strict)'.
TL;DR #SteffenUllrich is absolutely correct and should be the accepted answer.
This is your current setup.
You are gray-clouding the DNS record, essentially exposing your origin server's IP address to the whole world.
The first problem here is that, it is similar to posting your home's address on Twitter/Facebook, saying the front door is unlocked so feel free to come in and take what you want!
Cloudflare Origin CA Certificate
|
client <---------------------HTTPS-----------------> your origin (AWS)
The second problem here is that CloudFlare Origin CA Certificate is not meant to be used for client-server connection. It's purpose is to encrypt connection between Cloudflare edge and your origin only. You can think of it as a self-signed certificate. This is the reason for the error you're seeing.
One very simple solution is to replace this origin certificate with other free or paid SSL certificate such as Let's Encrypt/Certbot. If you decide to go this way, you can then skip the rest of below explanation if you want.
If you wish to keep using Cloudflare Origin CA Certificate however, keep on reading.
The next step is to proxy your connection to Cloudflare by orange-clouding the DNS record. Connection between client and Cloudflare edge will be encrypted using Cloudflare's free (shared) Universal SSL Certificate. It will partially solve the problem, but only half of the client-server connection is encrypted, because you are using Flexible mode. Connection between Cloudflare edge and your origin will not be encrypted.
Universal SSL Certificate
|
client <---HTTPS---> Cloudflare edge <----HTTP----> your origin (AWS)
The final step if to change the SSL mode from Flexible to Full or Full (Strict). Now you will get end-to-end encryption.
Universal SSL Certificate Cloudflare Origin CA Certificate
| |
client <---HTTPS---> Cloudflare edge <----HTTPS----> your origin (AWS)
Any questions?
I observed a site example.com has a cname mapping with mysite.com. Both example.com and mysite.com have ssl certificates.
Correct if I am wrong?
When a browser tries to connect https://example.com it checks DNS and finds it has cname mapping with mysite.com and connect to mysite.com web server directly.
When I observed browser it has ssl certificate for example.com domain. I am facing problem in understanding this case.
If request did not go to example.com web server how could browser get ssl certificate of example.com
or my cname mapping understanding is wrong?
or example.com private and public keys are shared with mysite.com webserver ?
DNS and TLS operate completely independent of each other.
TLS is used, among other things like encryption, to verify the identity of a server against its FQDN (Fully qualified domain name). This is done by checking whether the server in question is able to present a certificate, containing the FQDN, signed by a trusted certification authority (CA).
DNS is used to resolve host names to IP addresses, in order to establish network connections (like TCP connections) on a lower layer. How this resolution takes place is completely transparent to other components, like TLS. It does not matter whether the name resolution involves A, AAAA, or the mentioned CNAME record - in our context the input is always a single hostname, the output is always one (or more) IP addresses. Intermediate results, like CNAME mappings, are essentially discarded once name resolution is done.
This means that the TLS client always uses the FQDN initially requested by the user, regardless of any CNAME mappings, to verify the certificate. How to present a valid certificate is up to the server - sticking to your example, the server behind FQDN mysite.com will have to present a certificate valid for example.com in order for the client to accept it. How the private/public key of this certificate is generated, and whether it is shared with other certificates or servers, does not matter.
We would have to explicitly attach the SSL certificates of both the domains to the webserver/load balancer for both the domains to support HTTPS.
To understand this, it's useful to be aware of and understand SNI
When multiple websites are hosted on one server and share a single IP
address, and each website has its own SSL certificate, the server may
not know which SSL certificate to show when a client device tries to
securely connect to one of the websites. This is because the SSL/TLS
handshake occurs before the client device indicates over HTTP which
website it's connecting to.
Server Name Indication (SNI) is designed to solve this problem. SNI is
an extension for the TLS protocol (formerly known as the SSL
protocol), which is used in HTTPS. It's included in the TLS/SSL
handshake process in order to ensure that client devices are able to
see the correct SSL certificate for the website they are trying to
reach. The extension makes it possible to specify the hostname, or
domain name, of the website during the TLS handshake, instead of when
the HTTP connection opens after the handshake.
From: https://www.cloudflare.com/en-gb/learning/ssl/what-is-sni/
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. ...
I use squid 3.5 with its sslbump feature for https traffic filtering. I generated my private key and cert files with openssl. However,the browser received the warning message when i open https websites that the certificate was issued by an unknown authority. I created ssl certificates with comodo but i still got the same warning message.
Is there a way to remove this warning?
# Squid normally listens to port 3128
http_port 3128 ssl-bump cert=/var/tmp/example.com.cert key=/var/tmp/example.com.private
# Squid listen Port
cert=/var/tmp/example.com.cert
# SSL Bump Config
always_direct allow all
ssl_bump server-first all
url_rewrite_program /usr/bin/sh /var/tmp/middle_squid_wrapper.sh start -C /var/tmp/middle_squid_config.rb
# required to fix HTTPS sites (if SslBump is enabled)
acl fix_ssl_rewrite method GET
acl fix_ssl_rewrite method POST
url_rewrite_access allow fix_ssl_rewrite
url_rewrite_access deny all
You don't say what client OS you are using, but it sounds very much like you didn't import your squid certificate to the correct certificate store on the client.
When you install the certificate on a Windows client it should be imported into the Trusted Root Certificate Authorities'->'certificates folder.
The client should then trust the certificate.
I have a IIS 7 server hosting a few different sites. Recently I purchased and installed a SSL certificate to one of the site. Both http and https binding are setup with host header xxx.com and www.xxx.com.
But now i discover that other site with no SSL is loading the certificate and show the untrusted cert error when accessing through https.
Can i know how I can stop other non SSL site from loading the certificate?
Thank you.
I assume that
you are using the server on a single IP address
provide service for multiple names on this single IP address
have configured SSL for some of the names but not for others
This means, that
The server is listening on this specific IP address for SSL connections.
The server can only decide after receiving the initial SSL request from the client (ClientHello) which certificate it should use. The Client hash to use SNI (server name indication) to tell the server which hostname it expects. Most newer clients support this but for example IE8/XP does not.
Since the server has to listen for SSL connections on this IP address it can happen, that it receives a SSL request for a hostname, where it has not certificate configured. In this cases a server could do the following:
Use some other certificate it has configured. This is what your server is doing. This results in an error on the client about an invalid certificate since the name in the certificate does not match the expected name.
Simply close the connection or issue some SSL error. This would result in an SSL handshake error on the client which browsers usually display in a way so that end users are not able to understand what's going on. For the browser the situation is simply a server error and the server is not able to give the browser more detailed information (this is not part of the SSL protocol).
If you don't like any of these two problems you must serve the non-SSL hosts from a different IP address than the SSL hosts, so that the server will not even listen on the SSL port for connections for the non-SSL hosts.
I hope this explanation helps with your problem. If you have now specific questions about the configuration of the server to achieve the outlined solution you should ask them at serverfault.com instead.