Block all http (non-https) traffic
-
Hoping I am posting in the right section. Is it possible to block all HTTP (non-https traffic)? I don't want anyone visiting a non-https website and should therefore be blocked.
-
@macmichael01
firewall rules and block 80/443? -
@michmoor said in Block all http (non-https) traffic:
@macmichael01
firewall rules and block 80/443?He wants to block ONLY the HTTP traffic and let HTTPS pass. So, block only destination port 80.
-
@michmoor said in Block all http (non-https) traffic:
@macmichael01
firewall rules and block 80/443?He wants to block ONLY the HTTP traffic and let HTTPS pass. So, he need to block only port 80. If he blocks 443 as well, then HTTPS will not be allowed.
@macmichael01 said in Block all http (non-https) traffic:
Hoping I am posting in the right section. Is it possible to block all HTTP (non-https traffic)? I don't want anyone visiting a non-https website and should therefore be blocked.
You can block HTTP traffic by blocking connection attempts to destination port 80. But you might want to rethink that strategy. There are still a few HTTP sites out there users might need to visit. Obviously not sites for e-commerce or where you sign-in to do something, but there are just general info sites that are still HTTP. For example, I've come across several church and other charity-based info-only sites that are still using HTTP. For some types of sites, the confusion and overhead of using an SSL cert is not worth it. Especially if the site is simply a source of info and not designed to take merchandise orders or store user login credentials.
-
The reason for wanting to do this is that I found iOS (no matter what browser you use) first attempts to reach out to the non-SSL version of a website before it tries the SSL version of a website. I find this to be backwords in today's age and a potential security concern. OS's and Browsers IMO in today's age should always attempt the SSL version first and then fallback to non-SSL
-
@macmichael01 said in Block all http (non-https) traffic:
The reason for wanting to do this is that I found iOS (no matter what browser you use) first attempts to reach out to the non-SSL version of a website before it tries the SSL version of a website. I find this to be backwords in today's age and a potential security concern. OS's and Browsers IMO in today's age should always attempt the SSL version first and then fallback to non-SSL
There is a very good reason why iOS reaches out over http, and not https, as soon as the connection comes up.
Try other devices, with other OSs and you'll see that they all do this.It's part of the main 'connectivity test :
An iOS based device executes DNS request for "captive.apple.com" and ones it obtained the IP, it executes a web request : http://captive.apple.com/hotspot-detect.html - click on it (it's safe
)
If the single word Success is what's in the page the comes back, then the iOS device knows that it has an working Internet connection ...If "something else" (another text) comes back, the iOS device concludes its behind a captive portal. It will fire up a scaled down version of the default browser, and do executes the request again.
If an error came back, because you've blocked port 80 traffic, the (can ? will ?) device considers the connection 'not working'.
Microsoft OS devices, Androids, etc, they all to the same thing, they all 'ping to home' as a part of the connectivity test.
Why not https ? A https request could not be redirected, and this would break the captive portal functionality.
Another reason : a http request is simple and doesn't demand a lot of system resources.
Every device on planet earth, ones it connects, emits this 'test' request. The server "captive.apple.com" is getting slammed with http requests right now. If these were https, this would put a much greater load on these apple servers. (hint : there are many iPhones)You could try to create a list of all the IP addresses needed, and whitelist these.
-
@Gertjan is correct! I totally forgot about probably the most important reason you would not typically want to block HTTP at the firewall -- devices testing for a captive portal and verifying basic Internet connectivity.