Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
What is TLS and why do we need it. Can someone explain to me what roles does it play in Kubernetes?
What will happen if I don't use it? Can someone explain it to me with an example?
Thank you for your time.
What is TLS and why do we need it?
TLS definition from wikipedia:
The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications [...]
TLS supports many different methods for exchanging keys, encrypting data, and authenticating message integrity.
What roles does it play in Kubernetes?
It is used by k8s control plane for encrypting data in trasit. Encryption in transit protects your data if communications are intercepted while data moves between client and server. In case of k8s, e.g. kubelet or controller manager are usually clients and api-server is considered a server.
What will happen if I don't use it?
I am not sure if you can do this (not use it). I think its use is enforced by k8s components. All you can do is to ignore certificate validation.
But let's imagine for now that you managed to bootstrap a cluster without tls and all communcation is now plaintext based (meaning there is no encryption). Now if I manage to intercept the communication, I (malicious actor) can see what you are sending to the cluster. And since there is no mechanism to enforce data integrity, I can change this data to anything I want and pass it forward. You would have no way to check if you are exchanging data with the cluster or with me and if I am altering the data, adding malicious code or else.
Additionally, tls certificates are used by k8s components for authentication purpouses. This means that e.g. in order for kubelet to join the cluster it needs to prove that it is allowed to do this by showing it has a valid certificate, signed by known authority (this usually means selfsigned). You woudln't be able to verify that the kubelet is yours and that is's not some malicious kubelet I joined to your cluster.
Related
Disclaimer: Complete newbie trying to wrap my head around SSL.
I am developing a device using an ESP8266 which needs to connect securely to a known server for IOT purposes, we will develop and control the server endpoint as well as the ESP8266 based client (BearSSL etc), we will not control the SSL certificate updates on the hosted server and need to manage the changing certificate keys.
Using the SHA-1 fingerprint for the certificate installed on the server appears to be the most straightforward approach and will provide the basic security we need. The data we will be exchanging is not sensitive or mission critical, we just need to keep the web server happy going into the future.
I understand the need to update the SHA-1 fingerprint on the client when the server certificate updates and this would typically be done with a firmware update over a secure connection. Our use case will make this very difficult for various reasons, so I am trying to establish the best method for updating the fingerprint as it changes without requiring re-flashing/OTA updates.
What I don't understand is why there is a need to protect/hide/embed the fingerprint when any public user or hacker can visit our SSL server site and obtain the fingerprint through a browser or OpenSSL query. Can I simply not retrieve the current fingerprint (maybe encode it with our own basic encryption) from a known HTTP non SSL server perhaps running PHP which will obtain and calculate the current fingerprint of our SSL server for use by our IOT device ? Our device would query the HTTP server first, retrieve the fingerprint and store it in EEPROM until it expires, then simply re-obtain the new fingerprint as required. Then it goes off and talks to the SSL server.
So the crux of the question is, if a hacker can get the fingerprint straight from our SSL server, why would this be an unsafe approach, which I'm sure it is ?
I don't want to go down the trusted root CA with long expiry approach as our devices may need to run for 20-30 years and we'll need a device certificate update procedure regardless, and would prefer not to use ClientInsecure() if possible.
Assuming the non-SSL HTTP approach is no good, can anybody suggest an alternate automated method for retrieving the current fingerprint securely ? I have to assume our devices may get left in a cupboard or disconnected from Wifi for years at a time and need to automatically re-connect in the future without a firmware update.
Many thanks, and be gentle *8)
Your question may be removed as inappropriate for Stack Overflow but it's a really interesting one and I'm hoping you'll at least get a chance to see this answer.
First of all, there is absolutely no need to hide the fingerprint of the server's certificate. As you pointed out, anyone can get the fingerprint directly from the server itself.
If you're downloading the fingerprint from a different source in order to update your embedded device then it's not privacy you need, it's authentication - that you're getting it from the source you think you're getting it from - and integrity - that the fingerprint hasn't been corrupted or modified during transmission.
Which leads you to a chicken and egg problem. If you serve the updated fingerprint through non-HTTPS servers then it's vulnerable to modification and the servers are vulnerable to impersonation. If you serve it via HTTPS then you still have the issue of verifying the HTTPS server you're getting the fingerprint from.
You could use a pre-shared key to sign and verify the downloaded fingerprint. The embedded device would use a public key to decrypt a signed fingerprint, the server would have the private key to sign it. Then you face an entire new set of issues if the private key is every compromised - key revocation and distribution, which is part of the problem you're trying to skirt here with this whole process.
You're also going to want to do better than SHA-1. SHA-1 hasn't been considered cryptographically secure for years.
And in 20 - 30 years time, it's likely that whatever algorithm you're using will also cease to be cryptographically secure. Which means that you'll need to update the fingerprint algorithm over the course of decades.
Instead of using the fingerprint, you can embed in the device's firmware the top level certificate of the Certificate Authority that signed the server's certificate, but CA certificates will also expire well before 20-30 years elapse, and may also be revoked. If you embed the CA certificate then the web server will have to supply the embedded device with its entire certificate chain so that the device can verify signatures at each step, which on an ESP8266 may be very, very slow, even today.
In fact, it's quite likely that web servers 20-30 years from now won't use the same cyphers for SSL as they do today, and it's likely they won't continue to support the version of TLS (1.3) that's standard now. So you would need to be able to update your embedded software to TLS 1.8 or 2.0 or whatever the version will be that's needed 20-30 years from now. And the ESP8266 is not particularly fast at computing today's cyphers... it may be computationally impractical for it to compute the cyphers of decades in the future.
In fact, wifi 20-30 years from now will quite possibly not support hardware from today as well as wifi protocols evolve and also require updated cypher suites.
I'm also dubious that ESP8266's are likely to run continuously for 20 years without hardware failures. The main feature of the ESP8266 is that it's cheap, and cheap does not often correspond with reliability or longevity.
With much better performance, the ESP32 (still cheap) would stand a better chance to being able to compute the cyphers in use 20-30 years from now and support the future's wifi standards, but with its (and the ESP8266's) closed source wifi implementation you'd be at the mercy of Espressif to provide updates to its wifi stack 20 years from now, which I doubt will happen.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I understand what data encryption is and what role SSL plays in it, but I need to know what role encryption would play in an online game? I have heard many reports of SSL in games, heart-bleed being a popular one, but I just don't see the need for data encryption in games. If something as miniscule as terrain data is being transferred from server to client then what is the need of encryption?
What role does data encryption play in games?
What data should and shouldn't be encrypted?
If encryption is needed, which is better, SSL or TLS? Or are they used for different purposes?
I'm not familiar with games; however, what I know is that both SSL and TLS are used for encryption in web communications. However, SSL is almost dead (at least SSLv3) due to the several attacks it cannot handle. I don't know if you have lately visit a “https” site which uses SSLv3 using either firefox or chrome but they may say something like this:
Firefox:
Unable to Connect Securely
Firefox cannot guarantee the safety of your data on xxx.xxx.xxx.xxx because it uses SSLv3, a broken security protocol.
Advanced info: ssl_error_no_cypher_overlap
Chrome:
This webpage is not available
A secure connection cannot be established because this site uses an unsupported protocol.
Error code: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
So, the answer for your last question should be: Use TLS (TLS 1.2 if possible) instead of SSL. TLS in fact, is basically the evolution of SSL.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Using OpenVPN, I can enable 2-way authentication with certificates, private keys and a CA-certificate.
In my understanding, this only provides authentication (the client is, who he says he is) but not authorization (access control). OpenVPN just assumes that a valid authentication is also an access authorization.
If I now run a second VPN server, using the same CA, will the clients of the first also have access to the second VPN?
If I want to avoid this - clients with keys/certs for the first VPN server should not be able to access the second VPN server (and reverse) - what are my options?
use a different CA for each server (ugly in my opinion)
use an access control list based on the common name (CN) (not so practical)
use firewall / iptables (not so practical)
Am I missing a way to somehow limit access of a certain client to a certain server?
Citing Jan Just Keijser from the OpenVPN forum
openvpn provides authentication, not access control (authorization), nor should it, in my opinion. The options you mention are the only options you have, unless you also want to throw in username+password control.
you could use a sub-CA (intermediary CA) ; each client cert would be signed by a specific sub-CA ; the clients need only the "root" CA to connect to a server, but the servers can allow access based on the sub-CA used for a client.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
According to http://en.wikipedia.org/wiki/Secure_Shell#Key_management, ssh is vulnerable to "man-in-the-middle" attack when establishing the first connection with server.
SSH also supports password-based authentication that is encrypted by automatically generated keys. In this case the attacker could imitate the legitimate side, ask for the password and obtain it (man-in-the-middle attack). However this is only possible if the two sides have never authenticated before, as SSH remembers the key that the remote side once used.
Does VPN suffer from the same "weakness"?
If VPN server is authenticated using the key which is known to the client, then there's no problem - the key is already known (and supposedly trusted) and the client can be sure that it has connected to the legitimate server.
The same applies to SSH. Wording in wikipedia is not exactly correct - for the first connection to be reliable the client should know the valid server key. It's not important if "they have authenticated before". It's important that the client trusts the key.
How can the key be trusted on the client? When X.509 certificate is used in SSL/TLS, it's validated according to sophisticated rules and the certificate chain is built up to the trusted root certificate. If the chain can't be built, then the end-entity certificate is not trusted. In SSH there are no certificate chains and the only way the client can trust the server is when the client has server's key transferred using some other mechanism (voice call or paper or USB stick or separate SSL/TLS connection, whatever).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This is most likely not possible, but I'm just asking this to check... I'm just thinking out loud here...
So, SSH keys are very useful for logging into a server. Use SSH, and your SSH keys increase security to the server while also making it easier to manage several servers or other programs with one SSH key. Also, by unlocking the key when you login, there is even less need to type the password over and over again. So, I was wondering... is there a way to use SSH keys for website user verification? I am not talking about large, public websites, but about small, controlled systems that are used by specific users whose OS/browser can be controlled. Is there a way to integrate this? For this to work I assume the private key would need to be transferred over the web, so let's say we have SSL running to make this not insecure. Is such a thing possible? In an ideal situation, I log in to a website and it will see that my private key matches the public key that is installed, and voilá, I'm in!
It's called a client certificate, and you import it into your browser.
From technical point of view SSH keys represent public key cryptography scheme, and this is what X.509 certificates do in SSL. So what you need is certificates (client-side one if you want to authenticate the client on the server).
And no, private keys are never transferred across the net. They are used in certain operations for exchange of session key.
AuthUserFile /home/hafizni/.htpasswd
AuthGroupFile /home/hafizin/.htgroup
AuthName hafizin page
AuthType Basic
require group my-users