The Problem
browsers have no problem accessing my domain's website (https protocol) from a private network (home WiFi, personal hotspot), but if I try to access from a public network (my University's WiFi or Ethernet network, Costco WiFi, etc.), I get the following error message (happens on Chrome, FireFox, Edge, Safari (error messages are a bit different on Safari and FireFox)):
NET::ERR_CERT_AUTHORITY_INVALID
terp.app normally uses encryption to protect your information. When
Chrome tried to connect to terp.app this time, the website sent
back unusual and incorrect credentials. This may happen when an
attacker is trying to pretend to be terp.app, or a Wi-Fi sign-in
screen has interrupted the connection. Your information is still
secure because Chrome stopped the connection before any data was
exchanged.
You cannot visit terp.app right now because the website uses HSTS.
Network errors and attacks are usually temporary, so this page will
probably work later.
(By the way, it would give me the "because the website uses HSTS" message even before I implemented HSTS)
Background
I have set up an Apache2 web-server on my Linux VPS (Ubuntu 20.04). I recently configured everything so a domain I've purchased is accessible and working on this server:
DNSs redirect to server (domain is with Google Domains; VPS is hosted by Hostinger)
Redirect is achieved with custom records, which are two A records:
1st A record: Host Name: terp.app | Data: <VPS IP address>
2nd A record: Host Name: www.terp.app | Data: <VPS IP address>
Apache server set up with virtual hosts
set up an SSL certificate through letsencrypt.org (certbot)
I selected the option during this process to redirect http to https
configured DNS certificate authority authorization (CAA) so only letsencrypt.org-issued certificates are accepted
Achieved with one CAA record:
CAA record: Host Name: terp.app | Data: 0 issue "letsencrypt.org"
I enabled Strict Transport Security (HSTS)
Not sure if the fact that it is a .app domain has some sort of an impact
Bottom line, when I use ssllabs.com/ssltest/, I get an A+ grade: everything checks out. https connection has zero issues on private networks. I can confirm the problem from public networks doesn't have to do with a captive portal since I'm able to access any other website from these public networks.
Looking for a Solution
Yes, I know that I can navigate to chrome://net-internals/#hsts, and enter my desired domain name into "Delete Domain Security Policies." This is unequivocally not the solution I'm looking for. I want my site to work for users without them needing to do something like that. Other high-profile websites obviously don't have this issue, so...
How can I ensure my users will be able to access my site even when they're on public networks? Could it be because I'm using letsencrypt.org?
Related
Since Mozilla and Google announced, that they intend to activate DNS over HTTPS in the default settings in the future and the IETF approved officially the draft (https://datatracker.ietf.org/wg/doh/about/), I tried to understand the impact on our corporate network. It is now possible for every application to bypass the internal DNS Server (assigned via DHCP) and directly connect to a public DNS service. There is no easy way for an administrator to prevent application and users doing this, since all traffic is routed through HTTPS.
In most corporations that I know, there is a split DNS setup in place, allowing internal (intranet) and external (internet) name and IP resolution for the same domain name (e.g. mail.mycorp.example) with different resolve values. It also allows to add additional, intranet only, services like wiki.intra.mycorp.example, that would not be resolvable/accessible from the internet. Same goes for infrastructure names like server01.eq.mycorp.example.
The problem I see is, that if the application itself is preferring DNS over HTTPS and is not correctly falling back to the system assigned DNS servers, internal only domains would not be accessible.
I made an experiment with Firefox 61.0.1 (64-Bit) on Windows 10. I have set:
network.trr.bootstrapAddress = 1.1.1.1
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.trr.mode = 2
network.trr.mode = 2 should prefer DNS over HTTPS, but fallback to system DNS if no value received, mode = 1, which I also tried, should make a race and use the first valid result that Firefox gets back.
Unfortunately, after activating DNS over HTTPS in Firefox, all internal only websites did no longer work. All requests end in a timeout and fail therefor.
What do I miss?
Is there a better way to handle internal only DNS entries in future setups?
The exact configuration you described works in my corporate network. It first tries DoH for internal sites, then falls back to local DNS and internal sites resolve and load correctly.
I'm hosting a website on Windows Server 2012 R2. I'm able to access the site with no problem via the assigned ip address and as long as I'm on my home network. However, when I try to access the site using a public ip address, it defaults to my NAS (MyBookLive).
Baffled.
Thanks.
This is intentional.
When a user connects to your ip address, any inbound requests are blocked for security. You would need to open ports on your home router (most likely 80 and 443) and direct the traffic to an internal ip address.
Even if you do this, it is very likely that it would not work. Most residential internet providers do not allow you to host web/mail servers on the internet. If someone compromises your webserver, they would have access to your entire network.
You are better off with a dedicated hosting provider (AWS, Amazon, Google Cloud).
I have recently got an SSL certificate on my website, on the apache server that I am using to host my website. The website says "Secure" and also works fine when I run it over localhost using the laptops ip address 192.168.*.**. But when I try to port forward this website over the port 443, it somehow says unsecure and your connection is not private. Any help here will be appreciated.
It sounds like you are using a self-signed certificate for your https connection. While modern browsers such as chrome give you errors saying the connection is unsecure and perhaps you even see red lines crossing out the https at the beginning of your url, there is no need to worry. If you are getting your page to render with these characteristics all is working, the reason for the errors is because the certificate is signed only for you.
In a real world production scenario you would have to use a third party service for a public capable certificate. However for your own development purposes, as long as the page runs with https there all is working as it is intended to.
For more try reading this article.
We are a small, 300-seat organization with a mixed BYOD and Active Directory environment (Windows Server 2012 Standard, Windows 7 Enterprise) and we are having a very strange problem involving very specific-scope failures to resolve our organization's domain name on our domain-joined, company-controlled machines. For the purpose of this discussion, I'll use company.com instead of our domain name.
Background:
Active Directory Domain Controller is located at 172.16.1.3
The AD/DC machine is also running DHCP, DNS, and HTTP (IIS)
Our organizations websites at company.com and subdomain.company.com are hosted by IIS on the AD/DC machine
We have a split-DNS scenario in which the AD/DC server is used for internal DNS resolution but a different, off-site server provides DNS resolution for public queries
The IP address corresponding to company.com and subdomain.company.com is the public IP address used by a firewall at the edge of our network (both on the AD/DC DNS server and the off-site DNS server)
The firewall is correctly configured for NAT to pass HTTP and HTTPS requests it receives on its public IP address to the internal IP of the AD/DC server and reflects
Scenario 1:
A user on a domain-joined Windows 7 Enterprise machine is connected directly to our local network with local address 172.16.6.100 /16, issued by the DHCP server.
The DNS server entry is provided by DHCP (172.16.1.3)
This user is able to access the websites hosted at company.com and subdomain.company.com
Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the internal DNS server (172.16.1.3)
Scenario 2:
The same user on the same domain-joined Windows 7 Enterprise machine goes home and connects to the Internet using their residential ISP
The IP and DNS server entries for the client machine are provided by DHCP
This user can access any internet resources, such as google.com
This user cannot access the website at company.com or subdomain.company.com (a "host not resolved" error is returned)
When this user runs nslookup on company.com they DO receive the correct public IP address provided by DNS
HTTP/HTTPS requests to the IP address succeed and a webpage is returned properly by the server
This issue prevails across all web browsers
Using tracert company.com returns "unable to resolve target system name"
Using ping company.com returns "could not find host company.com"
When running Wireshark on the client before/during a failed request, no packets are sent by the client machine (either for DNS resolution or for an initial HTTP/ping/tracert request)
Restarting the DNS Client service does not resolve the problem
Stopping the DNS Client service does not resolve the problem
Using ipconfig /flushdns does not resolve this issue
Using route /f does not resolve this issue
Resetting the network connections using netsh int ip reset does not resolve this issue
Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the DNS server specified by the DHCP settings of the network used by the user
Scenario 3:
This same user on a personal (not domain-joined) Windows 7 Professional computer is able to access the websites at company.com and subdomain.company.com when connected to our local network
Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the internal DNS server (172.16.1.3)
Scenario 4:
This same user on a personal (not domain-joined) Windows 7 Professional computer is able to access the websites at company.com and subdomain.company.com when connected their home network
Edit: nslookup has been run in this scenario and correctly returns the proper DNS record from the DNS server specified by the DHCP settings of the network used by the user
Final Notes:
This issue seems to be generalized to affect all company-owned computers. We are using a common system image for all company-owned computers, which was just loaded in August. I have been scouring the internet in search of possible solutions and have come up empty handed so far -- I really appreciate any suggestions or advice you may have.
This is quite an interesting scenario. Looking at your scenario 3, user with personal computer can access the services but why is the DNS entry coming from your corporate IP and not users home DNS. Is the machine on company network?
Verify this:
When user tries to access service from home on company computer, is the IP details from home internet router or company network via VPN?
Can URLs be sniffed even though a client communicates with a server over SSL? I'm asking because I'm doing remote login & redirect to a physically different server via URL, and wondered if securing the communication via SSL would prevent replay attacks and the like.
The sniffer will know the IP (and probably hostname) of the server you're requesting from, and the timing/quantity of information transferred, but nothing else.
Yes, replay (and man in the middle) attacks are prevented by SSL if you don't trust a compromised root certificate.
An attacker can observe both the hostname (by watching your DNS traffic) and the IP address you're connecting to. The username, password and path part of the URL should not be available, however.
Of course, the client themselves always has access to this information.
The network sniffer would need both the public and private key to decrypt the SSL traffic.
SSL sets up an encrypted session between the two machines and then runs "ordinary" HTTP over that encrypted connection so they can see what physical machine you are connected to but beyond that can't see anything at all in your connection.
As others have said they can look at the DNS requests most likely to determine the hostname.
Also there are products out there which bypass this protection in a business environment by installing a new root certificate on the client machine and having a proxy server make the connection on your behalf, and then generating a "fake" certificate for the site generated using their root key to make the session to the browser so you appear to have a secure SSL connection to the server but in fact it's only to the proxy. You can look at the certificate chain for the connection to determine if this is happening but few people will bother.
So to answer your question - no the full URL can't be sniffed - but with access to the client machine it is possible to do it part way.,