From client I already have tls config which sets InsecureSkipVerify to true. How to write server for this client which take any cert.
Can tls.config help in server too? like setting InsecureSkipVerify to true?
No, as #JimB told you, TLS can't work without certificates.
The reasoning is simple: TLS is all about security, and certificates
are cryptographic keys which provide that security (TLS uses a so-called
"asymmetric cryptography" where each party has a key pair consisting of
a private and public parts; the public part is what get sent to another party
when doing a TLS handshake).
But on the other hand the security TLS provides is two-fold:
It provides mutual authentication of the parties participating in the
exchange.
It provides encryption of the transmission channel¹.
Certificates are used for both aspects: the fact they contain cryptographic keys is used for (2), and the fact they have owner's identity encoded
in them (and verified by whoever was issued a particular cercificate)
is used for (1).
Let me not digress into discussing how (1) works in detail
(though I truly urge you to read some theory on it) but (1) is what
you actually want to sidestep.
The good (for you) thing is that it's cheaply doable:
The TLS clients can be told to not verify the server's identity.
The TLS servers can be told to do the same (and often it's the default
mode they operate in—which is typical for regular websites
for instance).
You can create a so-called self-signed certificate for your TLS
server.
The latter requires nothing but something which is able to generate
X.509 certificates; OpenSSL is typically used for this;
just google for it.
If you're on Debian or Debian derivative (like Ubuntu, Mint etc)
consider installing the ssl-cert package and using
the make-ssl-cert program it provides.
¹ To be precise, they only protect the very initial phase of the exchange during which the parties generate and send to each other keys used for symmetric encryption, which are then used to encrypt the communication channel, and are regenerated (and re-exchanged) periodically. This is done because symmetric algoritms are way faster.
Related
Let's suppose, for example, I made a HTTP request to https://example.com and dumped following data
all certificates up to root CA that used to verify the server when the connection was made
all raw TCP traffic in both direction
all unencerypted/decrypted HTTP traffic in both direction
(optional) additional data generated by client
Then I want to prove that I did make such connection to https://example.com trusted by those CAs and the traffic is not fake or modified on client side, with assumption that the website is "trusted", e.g. it's securely configured and not hacked.
Is this possible?
If possible, what additional data is required to be dumped by the client and how to perform the verification?
With enough "additional data generated by client", yes, but the practical answer is "no".
The ciphersuites in use in modern TLS all use a feature known as "Perfect Forward Secrecy". The gist is that in addition to the stable asymmetric keypair used for server (and, optionally, client) identity, both the client and the server generate a random Elliptic Curve Diffie-Hellman (or classic Diffie-Hellman) keypair, do the (EC)DH key negotiation for the session master key, and then both sides promptly forget the temporary private key from that negotiation. Without either of those (EC)DH private keys you can't re-derive the integrity keys, so you can't prove the session.
Of course, if you could re-derive the integrity keys, then you could just forge the session afterwards. So I guess that, ultimately, either way the answer is "no".
I've been generating certificates for internal use at a company that may end up becoming more widespread as time progresses (rather than just on a single internal website). I've noticed that, when using OpenSSL, the certificates being generated show as using AES_256_CBC in Chrome, as shown below.
I've been wondering, is it possible to use other encryption algorithms with OpenSSL? I've seen certificates for other websites showing up as using algorithms such as RC4_128, and CAMELLIA_256_CBC.
If it helps, I have two versions of OpenSSL installed; 0.9.8l and 1.0.1c, and I'm using Windows 7. These certificates are also chained; one root certificate, one intermediate certificate, and then the certificate used for the website.
Thanks for your time.
Short answer
Yes, you can use other encryption algorithms but X.509 certificates play a very small role in that.
In order to do that without modifying the client you must configure your server to favour some cipher suites over the others (e.g. for Apache have a look at the SSLCipherSuite configuration).
If you can modify the client but not the server, you must reorder the cipher suites your client offers during the handshake. The ones with your preferred algorithm should come first. Alternatively, you can remove the ones with encryption algorithms that you don't like (even though that means that connections may fail because of that).
Long answer
The encryption algorithm used on a SSL/TLS connection is negotiated during the handshake. The client sends to the server the cipher suites it supports, ordered according to its preference. The server picks the one it likes most.
A cipher suite (e.g. TLS_RSA_WITH_AES_128_CBC_SHA) is a tuple that indicates which algorithms must be used for:
Authentication
Key exchange
Bulk encryption
Cryptographic digest
The content of the server X.509 certificate plays a small role in this process in that it limits how authentication and key exchange will be done. If the server certificate contains an RSA key, the cipher suite cannot be any of the ones starting with TLS_DH_DSS_*.
Theoretically, the server X.509 certificate is independent from the bulk encryption algorithm. However, since not all possible combinations are covered (or offered by the client), the type of key in the server cetificate may rule out some ciphers.
Minecraft uses a launcher on to reduce theft of the game: anyone can download without charge, but the user must provide credentials for a premium account to be able to update the game. I want to build a similar launcher (in Ruby) for a project, but I'm having trouble figuring out how to securely send the password over to an HTTP server (written with Sinatra, if it matters). Obviously, putting it as a parameter in a URL is a really bad idea.
Also, I've though about somehow sending it using password fields, but I don't know how they work (I don't usually do HTTP stuff). This is still a possibility.
Shorter summary: In Ruby, I want to send sensitive info over an HTTP request to a Ruby/Sinatra server.
Thanks for reading this!
Using password fields is no help. Not even when sent over POST. They are sent in plaintext, no matter how hard you try to hide them - that's the very nature of http.
You should definitely use TLS over https instead. The stdlib gives you Net::HTTP for that, but you may use any http client that supports https.
If there is money/value involved in this scheme, don't settle for anything less! Inventing your own protocol is
way more work (I admit TLS is not always easy to set up, but still a lot less work)
not secure in 99,9% of the cases
completely broken in the rest of the cases
No, honestly, inventing secure protocols is probably one of the hardest jobs out there. So be lame and stick to the mainstream (https), it will pay off in the end.
Edit:
You asked whether TLS costs money because of the need for a certificate. That's only an issue on the server side, in one-way authenticated TLS only the server needs to present a certificate, so clients connecting to that server will not have to buy such a certificate. If you operate the server, too, however, then you will need such a certificate. If you don't want to spend the money, you may look into hosting that gives you https for free. Heroku offers such a free service that I know of, and I assume there are other providers as well.
As #Len said, use HTTPS, or, if that is not an option, encrypt just the password with:
At the very least, XOR encryption
Maybe DES
Or RSA (total overkill, unless your game is worth the attention of power hackers to try to break your encryption, as RSA is banking and military grade)
You would then distribute a public RSA key with your launcher, the private on your server, and use those to encrypt the password (or, use those to encrypt the symmetrical encryption key).
I use a HTTPS connection without a valid SSL certificate. Is the connection safe? Is the information encrypted?
The connection is encrypted even if the SSL certificate isn't valid (expired, snake-oil, untrusted CA, etc.). The SSL certificate validation just makes sure you're connecting to the folks you think you're connecting to. Encryption doesn't do you any good if the folks decrypting your data are crackers instead of PayPal.
Actually it is possible to establish an encrypted connection between complete strangers without a certificate, using Diffie-Hellman or similar key exchange algorithms.
Alice and Bob agree on a random number x. Alice calculates
xa, where a is a large prime number known only to Alice, and sends that to Bob. Bob calculates xb and sends it to Alice. Alice calculates (xb)a, and Bob calculates (xa)b. Since (xa)b = (xb)a = xab, Alice and Bob now both know the number xab and can use it as an encryption key. The beauty of this is that Bob doesn't know a, Alice doesn't know b, and any eavesdroppers don't know either number (because calculating a from xa, in the case of large numbers, would take years).
As supercat points out, this by itself is still susceptible to a man-in-the-middle attack, and that's why at least one end of the transaction needs to authenticate using a certificate. To be accurate, though, it is not the server that checks this, it's the browser, and most browsers will let the user continue if the certificate is invalid (or possibly even garbage). In that event, the connection will still be considerably more secure than a regular connection. To listen in, you'd need to be able to manipulate IP routing or DNS lookups, and you'd have to set it up before the connection was first made, which is not easy to do.
BTW the keypairs in certificates are not what's used to encrypt actual traffic; they are used to establish a new single-use key for a much faster symmetric cipher (such as DES) which then does the rest of the work.
If there were no verification of SSL certificates, then someone who intercepted a communications channel could capture a request to connect to https://www.acmebank.com, send its own request to www.acmebank.com, and negotiate keys with both acmebank.com and the user. After that, it could receive each morsel of data from the user, decrypt with the user's key, and encrypt with acmebank's key, and do likewise with data from acmebank.com. The net effect would be that neither the user nor acmebank would see anything wrong, but the interceptor would be able to decrypt all of the data between the user and acmebank. The user and the bank will be using different keys to handle their communication, but neither entity will know this. Adding any standard aspect to the protocol to inquire what key is in use wouldn't help, since the interceptor could detect such queries and change the responses appropriately.
SSL prevents a man-in-the-middle attack by requiring the host to send the recipient a copy of the key the host is using, encrypted in a form that an intruder won't be able to fake (unless the intruder can fake CA credentials, at least). If one does not use a CA-issued certificate, there will be little protection against a man-in-the-middle attack, though the encrypted layer would prevent passive or retrospective decryption of session contents (BTW, I wish there were standards for something between unencrypted communication and SSL, for situations where passive or retrospective decryption are the primary threat, but I don't know of any).
Don't bother yourself anymore with invalid ssl certificate. You can now generate free browser valid certificate for your server as easily as you would generate a snakeoil (self-signed, browser invalid) certificate. Go see https://letsencrypt.org/ it's free and open to contributions.
Nope. What you're doing when using HTTPS is telling the browser to connect via a different port (443) whereas normally you connect via (80). Without a certificate, the server would refuse the connection. HTTPS is simply not possible without a certificate. Look here and you'll see a certificate is needed for it to work.
It's possible to establish an encrypted connection, yes, but it would still be possible that you're communicating with a cracked cpmputer instead of the real server. Like that, the cracked computer tells the server that he would be the client, decrypt all the data, store it and send the encrypted data to the client (and tell him he would be the server). So it's just a safe connection if there's no vulnerable point between the server and the client, which no one can guarantee.
I want to know how HTTPS is implemented. Whether the data is encrypted or path is encrypted (through which data is passed). I will be thankful if someone provides me implementation details.
Very simply, HTTPS uses Secure Socket Layer to encrypt data that is transferred between client and server. SSL uses the RSA algorithm https://en.wikipedia.org/wiki/RSA_(cryptosystem), an asymmetric encryption technology. The precise details of how the algorithm works is complex, but basically it leverages the fact that whilst multiplying two large prime numbers together is easy, factoring the result back into the constituent primes is very, very hard. How all SSL/RSA encryption works is:
The server generates two large prime numbers, and multiplies them together. This is called the "public key". This key is made available to any client which wishes to transmit data securely to the server. The client uses this "public key" to encrypt data it wishes to send. Now because this is an asymmetric algorithm, the public key cannot be used to decrypt the transmitted data, only encrypt it. In order to decrypt, you need the original prime numbers, and only the server has these (the "private key"). On receiving the encrypted data, the server uses its private key to decrypt the transmission.
In the case of you browsing the web, your browser gives the server its public key. The server uses this key to encrypt data to be sent to your browser, which then uses its private key to decrypt.
So yes all data transmitted to/from server over HTTPs is encrypted - and encrypted well. Typical SSL implementations use 128 or 256 digits for their keys. To break this you need a truly vast amount of computing resources.
As far as I am aware the request for a server asset is not encrypted - use httpfox https://addons.mozilla.org/en-US/firefox/addon/6647/ or Wireshark http://www.wireshark.org/ or something to confirm.
In two ways.
By ensuring that all information transmitted between you and the website is encrypted. It does this via a key-exchange process using RSA (which exchanges a 'session key', which is used for the actual encryption).
By (trying to) demonstrate trust in the website you visit. Certificates are provided to domains, and the idea is that on your machine you trust only certificates from various reputable sources. Then, you can (in theory) be assured that when a certificate pops up for "Your Bank", it is really "Your Bank" website, and not some other website. In practice, very few people care/notice this aspect of SSL.
It's transport layer security. It is not application level. You still need to follow secure coding practices and various other techniques to ensure that your site is secure.
I thought this was a really concise human readable explanation:
http://robertheaton.com/2014/03/27/how-does-https-actually-work/
Here is my summarised version:
Concepts:
Asymmetric cryptography algorithm – Public key encryption, private
key decryption.
Symmetric cryptography algorithm – Public key
encryption and decryption.
Handshake:
Hello – Client send cryptography algorithm and the SSL version it supports.
Certificate Exchange – Server sends certificate to identify itself, and certificate public key.
Key Exchange – The client uses Certificate public key to encrypt a new client regenerated public key (using the agreed asymmetric cryptography algorithm from step 1) and sends it to the server. The server decrypts it using its private key (using asymmetric cryptography algorithm).
Data Exchange - This public key is now know by both client and server. It is used for subsequent requests/responses for both encryption and decryption on both client and server (symmetric cryptography algorithm)
You can read all the details in the TLSv1 RFC-2246.
For security analysis, specifically the following section:
F. Security analysis
The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel.
This appendix outlines how TLS has been designed to resist a variety
of attacks.
further content snipped
Server and client do not have control over the path that is used to transmit the data. The path used is a matter for the network layer (Internet Protocol - IP), not for the Transport Layer Security (TLS)
The data itself is encrypted, and there are also means for checking server autenticity, as mentioned by Noon Silk.
http://en.wikipedia.org/wiki/Transport_Layer_Security