If you ignore the certificate warning the encryption still applied, but because it's an unauthenticated encryption, the encryption is useless against active adversary (an MITM adversary that can intercept and modify the data passing through it), as the active adversary can just reencrypt your connection.
The best practice to use self signed certificate in ...
Yes, the communication is still encrypted with self-signed certificates.
Self-signed certificates can be made by you, but they also can be made by any attacker. If you insist on using self-signed certificates, I would advice you to mark the certificate as trusted, so that you get a warning if an active man-in-the-middle attack is happening.
Creating your ...
Cryptography has three main security goals:
The certificate in the TLS/SSL handshake is used to provide authentication, i.e. to guarantee the client that he is talking to the intended server and not some Man in the middle attacker. Ignoring a certificate warning will kill this property of the connection.
As the previous answer suggests, the 2015/2016 attempt at this stunt got so much backlash they basically backed away from it and it sat for a while. The original January 1st 2016 deadline came and went with no real enforcement. Their request that Mozilla trusts their root certificate was declined. The MITM attempts still cropped up in individual cases of ...
Yes, the documentation you are looking for are the RFC documents for the various versions.
Here are the links to the RFCs for TLS 1.0, 1.1, 1.2 and 1.3:
Since this would be a link-only answer, here the core of each RFC.
The chapter 9. Mandatory Cipher Suits reads the following:
In the absence of an application ...
Does changing DNS help prevent MITM on ISP level?
In short: very likely just changing the DNS server will not help.
There are several technologies an ISP might use in order to redirect or MITM the traffic of a customer:
ISP provided DNS server returns a different IP address
This relies on the fact that most users will use the DNS server of the ISP. This ...
Encryption is still applied, the issue with self signed certificates is that you have no assurance that the server you are connecting to is who it says it is.
The problem is not so much that they are self signed, it's that they are not signed by some third party you trust. When you browse to a https website your computer checks that the certificate you are ...
You question isn't very clear. You wrote:
I'm connecting to that server via VPN (wireguard).
I do not route all traffic through that VPN, only DNS requests.
So, if the HTTP stream between your client and your server isn't routed throught VPN, then the connection isn't encrypted.
At contrary, if you route the traffic to your HTTP server ...
Let me just draw a MITM for you.
===| When you accept a self-signed cert |===
===| and get lucky |===
+--[Your browser]--+ +--[Server S]--+
| accepts cert A | | has cert A |
| sends +---------------------+...
Old question, but I'm studing a similar architecture on AWS, and has been a long journey.
The first question to answer is if is possible to configure AWS load balancers (ELB at the time, ALB and NLB now) to perform mutual TLS authentication.
This requires understanding of the mutual TLS authentication works. A google search can help you more than a ...