SSL - Cloudflare, avast or my code? - ssl

I have 2 websites on 2 servers, I use the SSL cloudflare
For the first everything is ok, green padlock.
For the second, I have a grey padlock with a warning on it https://lightpics.net
Google Chrome can see the site’s certificate, but the site uses a weak security setup (SHA-1 signatures), so your connection might not be private.
Proceed with caution. These are common mistakes in websites' configurations, but that doesn't guarantee that your connection is secure.
When I disable the HTTPS verify in Avast, it become green.
Someone know why ? I have the same configuration on the both... so, it's my server, my code, avast or cloudflare ?

The problem only came from avast : it MITM your connection and sign it again with an sha1 certificate.
To be sure, check your server with ssllabs.com
Just one more thing : https is not enough to be secure, you should redirect http to https with a 301 (permanent) redirect and use HSTS.

Related

cloudflare SSL in Full(strict) mode still non-ssl connections

Stack:
Cloudflare
SSL in Full(Strict) mode
Always Use SSL is ON
Heroku
Automatic Certificate Management (ACM)
All this seems to work well, except that on the Cloudflare SSL Overview tab, under Traffic Served Over TLS 30% is labeled None (not secure) I would expect this section to have started to approach zero.
The settings above have been in effect for well over 24 hours.
So, where's all this non-ssl traffic coming from? Is that just traffic coming in over HTTP that Cloudflare is redirecting to SSL before it gets anywhere else? Or is it something else?
Yes, it's very likely that traffic is coming in over HTTP that Cloudflare is redirecting to SSL. When someone first requests the HTTP version of the site that will be handled over HTTP (not HTTPS), which will then redirect to the HTTPS version.

Make a domain point to another https domain

I am facing a weird issue. I do not know if it is Nginx related or DNS related but here is the problem :
I have a domain that is fine, let's say foobar.com , SSL does not face any issue. Both www. and root domain work with HTTPS.
I have a second domain, let's say foobaz.net, I need to redirect it to foobar.com in every situations (both www. and root domains).
It does actually redirect, but when I try to access https://foobaz.net/ I get a HTTPS error/warning before being redirected to https://foobar.com/ after adding it the the SSL exceptions of Chrome (https://foobar.com/ SSL certificate is OK once I get past https://foobaz.net/ SSL warning).
I do not know if it is Nginx related or DNS related, any clue of what is happening here ?
Thanks in advance.
Any https connection checks the ssl certificate before proceeding to do what it needs to do in the server(in your case, a redirection). You may have a certificate for foobar.com, which is perfectly fine, but if you don't have a valid foobaz.com certificate. That's why the error shows up, foobaz is not "secure".
A https connection is secure if all the points between you and the endpoint are secure, not only the endpoint. If foobaz is not certified, that is a non-secure middle point on your connection, and that's why the warning happens.
Get a SSL certificate for foobaz too, and the whole connection will be secure.

SSL needed on redirect?

I inherited a weird situation from a client that I'm no expert at. This client has 3 domain names, the main one being, for example, domain-a.com. They also have domain-b.com and domain-c.com redirecting to domain-a.com. All domains live on the same server.
So the problem comes up because they had SSL certs on all 3 domains and the cert on domain-c.com expired and they need to get a new one. This had me thinking, do they even need certs on domain-b or domain-c if it just redirects? Also consider that the domain-c.com domain is the domain of their email, but as far as I know, the two don't affect each other.
TL;DR: Do you need SSL certs on redirects to a page with an SSL cert.
Yes.
The redirection is an HTTP-level action which happens inside the SSL envelope.
The client needs to establish an SSL connection to the original host before it 'sees' the redirect, then after completing the redirect it must establish another SSL connection to the target host.
So you definitely need an SSL certificate on redirects to a page with one.
If you have requests via TLS to domain-b & domain-c than yes, you need TLS support on them.
There's also a security related aspect in this. Plain text communication to domain-b.com & domain-c.com means a plain text redirect to domain-a.com. Because it redirects to SSL only the communication to domain-a.com is secured. This leaves the redirect from domain-b & domain-c vulnerable to a MITM attack. An attacker can intercept the requests and redirect the client to a different site under their control.
This is not easy to prevent, unless you have something like HTTP Strict Transport Security (HSTS, RFC) in place on all domains and the visitor visited the sites before or they're in preload list of their browser.
In any case, to make it more secure: Upgrade the client to TLS on their first request to any of the three domains, and redirect to https instead of http when going to domain-a from domain-b & domain-c. Use HSTS with preload and HTTP Public Key Pinning on all domains and you're good to go.

Nginx(reverse proxy) cant forward SSL certificate of https backend to clients

I have made reverse connection to one of web servers on which is SSL applied and the the content is in dir (http://webserver.com/directory) ,so i had to use rewrite rule and that works well.
The thing is that nginx can't pass SSL from backend webserver and i get error on silverlight application..
Could someone advise me on what to do ? Config is very basic as only rewrite is added additionally.
Looking forward for suggestions,ideas,answers.
Best regards.
Edit: pastebin.com/SnyHaUL4
As far as i know, you could say that "it's not a bug, it's a feature", one of the features of SSL that it prevents Man in the middle attacks, if you want to use SSL then nginx it self should have an SSL key and allow https connection, otherwise the user will see the well known yellow warning page about untrusted SSL,
If you implement the SSL for nginx, then the connection would be like this
client -> nginx ssl -> nginx -> server ssl -> server
The connection will be encrypted and decrypted twice on the way to the server, the client wont see the server SSL and will only see the nginx SSL.
If you don't have or don't want to use SSL on your nginx, then you need to make the connection to it unsecured, then the warning won't appear and every thing would work fine.

How do I make apache SNI hosts without certificates redirect to http address?

I have an apache server with multiple named hosts all working fine for port 80 http traffic.
(A VPS with one unique IP address)
I have one domain that has a SSL certificate and that domain is configured to handle both http and https traffic.
However if someone accidentally adds https to the beginning of a none SSL configured URL I get a typical certificate warning error (expected) and then if the user accepts the error (depending on the browser) it displays the SSL site I have configured instead of the original non-ssl domain.
I've read up a bit about SNI, but I don't have certificates for each of the other domains and would rather the server either not respond to the SSL request on anything else but one specific domain or redirect to the http version of the site.
Suggestions please as to how I approach this.
Kind regards, Spencer
For security reasons, what you're trying to achieve cannot work.
The browser (which implements the mechanisms to check the certificate) cannot know whether the user typed https:// instead of http:// accidentally or intentionally. Since it's ultimately up to the users to check that https:// is used when they think it's required, browsers should simply perform the actions requested by the users.
A redirection from https:// to http:// should always start with a valid https:// connection. SNI won't help you much there if you can't have valid certificates for the initial connection.
Otherwise, it would be fair for browsers to assume there may be a MITM attack in progress. Typing in https:// explicitly (or using HSTS) is the only reliably mechanism against MITM tools like SSLstrip, which would otherwise be capable of downgrading (or preventing an upgrade from http:// to https://).