The servername tag was the difference. $ openssl s_client -crlf -connect example.com:443 -servername www.example.com GET / HTTP/1.1 Host: example.com [ENTER] Apache 2.4.6: [Sat Mar 05 18:13:23.217568 2022] [ssl:error] [pid 22316] AH02032: Hostname www.example.com provided via SNI and hostname example.com provided via HTTP are different Apache 2.4.52 does not produce this error in the log file. man openssl-s_client

A privileged user is able to install some software doing network interception and also add a new trusted root CA. This together makes it possible to do an active MITM attack on the TLS traffic, and thus listen and even modify the traffic. This is similar to what many antivirus products do.

The browser generally requires the website to provide an SCT (Signed Certificate Timestamp) signed by the logs which have logged the certificate. This means that while the browser may not immediately verify that the certificate has actually been logged, they still have a promise from multiple log operators that the certificate has been logged. Given chrome's https://googlechrome.github.io/CertificateTransparency/ct_policy.html , it would require the cooperation of at least three rogue entities (one CA and two log operators). While this is not completely ideal, it is significantly better than the previous approach of having a single point of failure. Not all browsers perform SCT auditing as this becomes a significant privacy. However, chrome implements opt-in https://docs.google.com/document/d/1G1Jy8LJgSqJ-B673GnTYIG4b7XRw2ZLtvvSlrqFcl4A/edit where the browsers sends the SCTs it receives to google, which then checks if the certificates have actually been logged.

To visualize A. Hersean's answer: End-to-End In-Transit ┌───┐ │ ┌───┐ Client│ │ hello │ Client│ │ hello └─┬─┘ │ └─▲─┘ │ uryyb │ │ uryyb ┌─▼─┐ │ ┌─▼─┐ Server│ │ uryyb │ Server│ │ hello └─┬─┘ │ └───┘ │ uryyb │ ┌─▼─┐ ├──────────────────── Client│ │ hello │ └───┘ │ ┌───┐ │ Client│ │ hello │ └─┬─┘ │ │ uryyb │ ┌─▼─┐ │ Server│ │ hello │ └─┬─┘ │ │ uryyb │ Client┌─▼─┐ │ │ │ hello │ └───┘ │

if I manually change the address bar URL from http:// to https:// in a website I visit does it provide security regarding the connection? Yes, it provides all the standard things TLS provides: Authentication (you know you're talking to the expected webserver, not to some attacker impersonating it). Confidentiality (your network traffic to and from the server is encrypted; no attacker can know what is sent in each direction). Integrity (your network traffic is secure against tampering; you know that the server sees what you sent, and you see what the server sent, without modification en route). Mind you, there's lots of stuff that HTTPS / TLS doesn't provide. It doesn't fully hide who you're talking to. It doesn't conceal how much data you send or receive. It doesn't give you the ability, after the fact, to prove somebody said something (nobody knows whether you modified it in the meantime, see e.g. fake Twitter screenshots). It doesn't hide your IP address or otherwise make your location unknowable. It doesn't protect you from vulnerabilities in the web application. It doesn't mean that content you receive is safe to open. Because all the websites that I visited so far which were using the HTTP protocol and I did this worked. I know that major websites redirect from HTTP to HTTPS. It's a little surprising that this would work on all websites that you tested, without any errors. Most sites that fully support TLS automatically redirect to HTTPS these days, and the rest usually have incomplete configurations (untrusted or expired certificate, certificate issued to a different site such as the hosting provider of your target site, outdated protocol support). I know of a few such examples. Still, it's good news that HTTPS support is so widespread now. So if I do this and it works, does it simply mean that the website is not redirecting to HTTPS? Yes. If the page loads correctly and without any warning message (and are using a modern browser), that means your connection is secure and you could do all your browsing for that site via the secure connection. There's even a browser extension to do this for you on a lot of sites where it's known to work: https://www.eff.org/https-everywhere . Mind you, as https://security.stackexchange.com/a/259773/53333 , sites that aren't specifically intended to be used with HTTPS may have links (or other forms of navigation) within them that explicitly redirect back to plain HTTP. Also, even if you do all your browsing for that site over HTTPS, any cookies it set on your computer might still be vulnerable to a network-based attacker (somebody on your LAN, or otherwise between you and the server), so be very wary of signing in (or otherwise doing anything unauthenticated) on a site that supports plain HTTP (in any way other than a redirect) at all.

SSL protects the transmission from 3rd parties, but does nothing to protect you from the hosts you connect to File integrity only matters if you are comparing the file to a known-good file. If the file is already bad, integrity won't protect you from that. The type of P2P described in the article is about file-sharing networks: "A P2P network is a group of computers on the internet that have agreed to share files with one another. " A 3rd party will find it very difficult to inject malicious files into a stream, however that isn't required at all. All a malicious 3rd party would need to do is simply join the network and serve the malicious file directly ... no 'hacking' required when people just accept the virus...

Encryption is only useful, if the information is only encrypted for the intended party. Certificate validation in HTTPS ensures exactly this, i.e. that the encryption is established with the expected server and not with some man in the middle. Therefore it is a bad idea to completely disable certificate validation. And using self-signed certificate does not actually require to completely disable certificate validation. One way is to provide the certificate to the client before connecting so that it can be imported as trusted. Another way is to "TOFU" ( https://en.wikipedia.org/wiki/Trust_on_first_use ), i.e. connect to the server, accept the certificate after the issued warning and then remember this certificate as the expected one for future connections. This is what browsers do. And in company environments it is often expected that administrators can use certificates issued by their internal PKI for the device, so that no certificate warnings need to be skipped.

Your question is ambiguous. If you question is about not wanting anything to reach the destination server unless it reaches port 443, and for that iptables is the answer. If your question is about connecting to SSH by passing inside a TLS tunnel first, it's not that simple. You cannot just throw SSH on a SSL tunnel and expect it to work. You need something to encapsulate SSH traffic before the tunnel, send it thru, and something else to de-encapsulate the traffic later and send it on its way. Something like https://www.stunnel.org or https://hitch-tls.org .

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security simply informs the browser that it should only access the site by HTTPS and not by HTTP. It does this using a response header that the site serves when the user's browser connects to the site. The site owner can petition to have the site listed in an HSTS preload list that some browsers will load. So, in order for HSTS to be effective, the user must have visited the site previously, or the site must be in on HSTS preload list that the user's browser loads. So, even with HSTS, there is still an opportunity for an attacker to pull off an MITM attack - if the attacker can manage to get a certificate for the site signed by a CA that the user's browser trusts, or dupe the user into trusting the certificate. And, even if the site is configured to send the HSTS header, the attacker may also be able to pull off an https://security.stackexchange.com/questions/41988/how-does-sslstrip-work attack, if the user has never connected to the site before, and the site is not on an HSTS preload list that the user's browser loads.

TLS is at application level. It runs over TCP, not below it. There are lots of examples of TLS out there, and it will depend on what language or framework you are using. If you are skilled enough to develop an application that sends monitoring data to a remote unit, TLS will be trivial. Basically, you will need: TLS Server running on the monitoring unit, or on a relay server TLS Client running on the tablet device A trusted certificate on the monitoring server, or the relay server You only have to decide if you are going to use public CA-issued certificate, internal CA-issued certificate, or self-signed certificate, in decreasing price and protection order. Public CA-issued certificates are the most secure. That's the kind of certificate your bank uses. They usually expire in 1-2 years, so forgetting to renew them will create availability issues. Private CA-issued certificates are free, but you have to install a CA certificate on the clients, and not everyone will like this. The reason is because a certificate issued from this CA have the same trust as a public one, and if someone compromises this internal CA private key, they can impersonate any site. Self-signed certificates can be very secure, or completely insecure, depending on how you deploy them. If you issue a self-signed certificate and use public key pinning on the application, it's a very secure solution. An attacker would have a difficult time sniffing the traffic and having the data in the clear. But just issuing a self-signed certificate and installing on the server is not secure at all. Any attacker that is MitM position could just issue a certificate with the same fields, decrypt data in one side and re-encrypt with his own certificate, and the client would probably click on the "Insecure Connection" warning anyway. Storing the private key is the main issue you will face. You could just store it on the monitoring unit file system, and if someone gets the key, they could decrypt any data coming from it. If every single monitoring unit uses the same key, one leaked key means no unit is safe anymore. That's why using a relay server is optimal: you would use a TLS client on the monitoring unit and send it all data. TLS Server would run centralized, on this server, and it would relay the data to any tablet you have.

How do I differentiate between those that are able to MITM me and those that aren’t? Are there any signs/description on the usage of the certificate that makes them distinct? CA certificates usable for MITM and usable as trust anchor in WiFi authentication are not really different. The difference is how these certificates are installed in the device: If they are specifically installed for authentication against a WiFi network only, then they will be only used for this purpose. If they are instead installed as a general purpose CA then they will also be used as a trust anchor in web traffic and other TLS connections and thus can be used for actively MITM TLS traffic. But note that in your specific case you are not dealing with a CA certificate at all. You are only asked to install the leaf certificate specific for your current network. This can be seen from: Certificate Authority: No A CA certificate would have a "Yes" here and only a CA certificate is able to issue other certificates as needed in active TLS MITM attacks.

Yes, it's still a concern, although you can probably mitigate the risk by using an Elastic IP in AWS, or a VPN or similar. It's a concern because anyone with a "valid" credit card can create an account in AWS and run whatever they want. I wouldn't be surprised to find out that many instances are taken down each day because they show evidence of malicious activity. I'm sure AWS does lots of good work to try to prevent this, but realistically there'll be too many bad actors to catch them all.

TLS using a domain name is resistant against DNS spoofing since the expectation given by the user (domain name) is checked directly against the certificate without any additional party involved. While DNS spoofing might result in the client connecting to the wrong server, the certificate check will fail (assuming strict checks and no compromised certificate) before any application data are transmitted. Your approach instead relies on the security of DNS. While forward-confirmed DNS lookup is definitely more secure than a simple reverse lookup, it is still vulnerable to DNS spoofing attacks unless DNS itself is secured against such attacks (using DNSSec). Thus, your approach is not as secure as checking against a user provided domain name. But it is definitely far more secure than not checking the subject of the certificate at all as was done in the past. If this "far more secure" can be considered "sufficiently secure" you have to decide yourself based on the specific risks in your environment.

Do not reuse the same certificate and private key on multiple devices. The private key can and will be extracted from the device. Even if you managed to install a valid & CA signed certificate, anyone would be able to mimic your server. A man-in-the-middle situation would be equally insecure compared to using plain HTTP or a self-signed certificate without manual validation of the fingerprint. The correct way Every IoT device having enough computing power should behave like this: During the initial setup (and at any point after), allow the user to decide the hostname of the device. It could default to the IP address of the device, which would be fine if the client chooses to use self-signed certificates. Create a random key for the individual device that isn't just derived from predictable variables, like the serial number or MAC address of the device. Neither stick with a static key for the device for its entire lifetime; generate a new one every time. Using the random key, create a self-signed certificate for the hostname. Allow the user to download a certificate signing request (CSR). The user can now sign the certificate in a way appropriate to their infrastructure, whether it's a local PKI or a public CA, using a FQDN of a (sub)domain they own. Allow the upload of this certificate. Validate it's still a pair of the private key and replace the self-signed certificate with it.

The first message from the server to the client (ServerHello) includes a random challenge which changes every time. The client proves that it knows the private key corresponding to its certificate by sending a signature (CertificateVerify) of all the handhsake messages received so far, including the random challenge. A third party that doesn't know the private key can't replay the connection, because the server will send a different random challenge each time. The mechanism is exactly the same in the other direction. The client's first message also contains a random challenge, and the server must sign data that includes this random input. (That's in cipher suites that use signatures for authentication. In cipher suites that use asymmetric encryption or pre-shared keys, the server instead proves that it can decrypt some data that depends on the random challenge.) You can see the details of a typical TLS connection in https://tls.ulfheim.net . The server's signature is at the end of the “Server Key Exchange” step. This example doesn't use client authentication; if it did, that would be an additional part in “Client Key Exchange” with similar content. If you want all the details, they're in the specification. The term to look for is CertificateVerify. https://datatracker.ietf.org/doc/html/rfc5246#section-7.3 (TLS 1.2) and https://datatracker.ietf.org/doc/html/rfc8446#section-2 (TLS 1.3) have a summary of the handhske protocol. https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.8 and https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.3 give the content of the CertificateVerify message.

In 1.2 and below tickets are beneficial if you have so many clients storing sessions on the server takes too much space, or you have multiple server instances (i.e. a 'farm') that must handle traffic from the same client(s) and can't easily share dynamic state but can preshare a key for the tickets. The first doesn't apply upstream of a proxy; the second might, depending on details you didn't tell us. TLS protects the channel, not the endpoints. If the channel is now consistently over a few (probably more-or-less fixed) networks instead of "all the Internet", that reduces the attack risks to some extent, but whether this is enough to increase key lifetime is a judgement call. But if you're subject to a law, regulation, or policy, for example PCIDSS or HIPAA or GLB, usually the effort to get and maintain an exception is more than the effort of just taking standard precautions even when they aren't needed. Note in 1.3 both the old session-id resumption AND tickets are replaced by a single new dynamic-PSK method, so this choice becomes moot. Compare https://crypto.stackexchange.com/questions/15209/compare-rfc-5246-sessionid-re-use-versus-rfc-5077-session-resumption (disclosure: my answer)

You are correct; TLS provides no protection at all against malicious clients. You can think of TLS as providing a tunnel between the client and server. What's going through the tunnel is protected against attack from outside the tunnel, but it doesn't control what goes through the tunnel at all. Therefore, it doesn't protect against attacks launched through the tunnel (in either direction).

The -k option with curl disables certificate verification for https connections, but it does not downgrade the connection from https to http. This will allow your https connection to proceed, despite the fact that the server's self-signed certificate is not signed by a CA that curl recognizes. However, this also has the adverse effect of allowing a https://en.wikipedia.org/wiki/Man-in-the-middle_attack to use his own self-signed certificate to impersonate the server, and intercept the connection. A better solution would be to add the certificate to the local trust store, so that curl recognizes it, or to use the --cacert option with curl to tell curl to trust the certificate. See https://curl.se/docs/sslcerts.html for more info.

TLS guarantees three properties of the data exchanged inside the connection: confidentiality, authenticity and integrity. This is all under the assumption that the endpoints and the public-key infrastructure are secure: here we're only concerned about attacks on the network (eavesdropper, man-in-the-middle). Confidentiality means that an adversary can't learn what data is exchanged over the connection, only its size and the time at which it is exchanged. Authenticity means that you can be sure that your machine is connecting to the expected server. Integrity means that an adversary can't alter or modify the data exchanged over the connection. (Not even just to replay an old, unmodified connection.) The main limitation is that an adversary can change and modify data that isn't exchanged over TLS. This includes non-TLS links that you might accidentally follow. This also includes server names: DNS is mostly not encrypted. An adversary can't trick you into connecting to the wrong server by modifying DNS traffic (if it tries, TLS's protection will prevent your browser from connecting to the wrong server), but they can learn which server you're connecting to. (Just the server name, not the full URL.) These days, most of the web uses HTTPS, so the main advantage of a secure wifi is that DNS gets encrypted. Note that secure wifi doesn't just mean encrypted wifi: encrypted wifi provided by someone you don't trust is no better than non-encrypted wifi.

If an attacker gets a certificate for example.org, couldn't he/she perform a MITM attack on my website? The big word here is "if". This is why ownership validation exists. In order for an attacker to get a certificate by a trusted CA, the CA needs to validate that the attacker actually owns the domain. Sure, I could request a certificate for example.org, but I cannot in any way prove that I own the domain. So as a result, no trusted CA would sign my request. In fact, if they would and it would become public, it is very possible that that CA would no longer be trusted - which, of course, would be a worst-case scenario for them. The situation in Kazakhstan is very different. There, the government and all ISPs intercepted all internet traffic, violating all TLS guarantees. As a result, all browsers there will display "This site is insecure!" and urge users not to visit them. A security-conscious user would reject the connection and then...not have internet connectivity anymore until the MitM attack ends. Other users would continue, knowing their connection is being intercepted. The reason this is different is that the Kazakh government doesn't have a valid certificate for any site, which is why this warning appears in the first place. As schroeder pointed out in the comments, merely owning a certificate isn't enough to perform a Man-in-the-Middle attack. In order to perform that, you need some way of redirecting your target to your system. This could be done locally via ARP spoofing, or remotely via DNS hijacking.