How does that work?
They seem use an In-the-middle SSL Bump proxy.
First, it works as a transparent proxy, meaning it will silently redirect all HTTPS traffic to SSL Bump proxy servers.
You have to install and accept the proxy's Certificate Authority cert to make this work.
Once done, each SSL connection is made from your host to the SSL Bump Proxy with ...
However, in this scheme, couldn't an impostor just present the
certificate after getting it from the real server?
An impostor cannot present, and take advantage of, the real server's certificate unless it also has the matching private key. This is true whether the SAN DNS entry or IP entry are used to identify the certificate being presented.
Is the only protection here that Bob actually checks that the public
key on the returned certificate matches what he originally sent in his
request to the CA?
If the public key was switched before the CA used it to create the certificate, then Bob's web site won't work at all. The private key, which he has kept safe, will only work with his original ...
Is it dangerous to add a custom cert authority to a browser?
It is pretty dangerous. The owner of this CA can use it for man in the middle attacks or to impersonate arbitrary web sites since your browser will trust the CA to create certificates for arbitrary sites. Using such attacks he can then intercept your passwords and other sensitive data.
When the attacker sends the server's certificate, the client will encrypt a shared secret (used to generate the symmetric encryption key for the session) with the public key of that certificate. The attacker will then be unable to recover the secret since they don't have the certificate's private key, so they won't be able to complete the TLS handshake.
You used "security through obscurity" in quotes, so I don't think I need to convince you that that is not going to work.
To achieve your goals, you will need to encrypt the connection between the clients connecting and the server (with a logon). HTTPS is the simplest, lowest effort, and cheapest way to do that.
But you can also consider things like ...
Good question. The certificates of the most trusted CAs are normally included into software install package, e.g. into browser installer, into OS installer, or are preinstalled on device like smartphone. That's why the browser (or some other application) will notice if certificate is really from the specified CA.
The checking of the hostname is done in X509_check_host. This function calls the internal function valid_star to make sure that the given wildcard in CN or SAN can actually be used.
This function checks that wildcard-CN/SAN like * or *.com are treated as invalid since they are too broad. *.example.com is instead acceptable. Thus check is done by counting ...
The scheme you are describing is called "Hybrid Encryption for Multiple Recipients" and is already well-implemented in GnuPG.
The user David Segonds described it well in this answer on StackOverflow:
GnuPG does multi-key encryption in standard.
The following command will encrypt doc.txt using the public key for Alice and the public key for Bob. ...
The certificate and DNS record for IP public are irrelevant, you can buy any certificates without publish your sites. All you have to do is to prove you are the owner of that domain by clicking the approval link which send to your domain registration email or a DNS TXT record only.
What's the best method/solution for protecting the integrity and identity of end-user certs?
Install an HSM on their devices and use keys stored within it for VPN. Expensive and difficult to set up.
I want to make sure that users only able to use VPN with company provided devices.
Then instead of trying to control the keys, which is difficult, use VPN ...
Browsers will alert the user if they are presented with a self-signed certificate which they don't trust.
The browser user or system administrator should preempts this scenario and add the self-signed certificate to the browser's trust-anchor store beforehand. That way, the user won't see a warning.
Done this way, users can be informed that if they ever ...
Browsers will only accept an invalid certificate - and self-signed is one form of "invalid" - when the user acknowledges the risk and overrides the browser. The specific steps for doing so vary from browser to browser, but they're usually onerous by design - they want the decision to bypass security to be hard, not easy.
For inspiration, look at how SSH key exchange works:
The client maintains a table of "known servers" that matches an IP address to a hash. When connecting to a server, the client receives the server certificate (public key) and computes the hash of it, and looks up the server's IP address in the "known servers" table.
If the client has seen this server ...
Installing additional Root CAs to your PC can give others significant access to your network communications depending on how trustworthy the operators of that Root CA are. You rely on Verisign abiding by its Certificate Practice Statement (CPS) and only issuing certificates to authorised users of the represented resource.
In this case you are installing a ...
The certificate is one part of the whole system. The other part is the school router which should be CyberHound Appliance.
When your browser connects with a site with https, the flow goes roughly like this:
Browser initiates connection with the server
Server returns its own certificate and a chain of certificates reaching up to a well known Certificate ...
As long as you control DNS, it's trivial, even with Let's encrypt. Simply use DNS validation with LE, and they will happily issue a certificate. The point of this process isn't to ensure that anyone can use your site (that's your problem), but to ensure that noone will get a certificate for sites they don't know.
With many paid certificates, you can ...