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.
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".
From what I understand SSL uses asymmetric cryptography to securely exchange a session key generated by the client, which is then used for symmetric encryption. I have a few questions on this
How long is this session key valid?
How does the server keep track of which session key is valid for which client? Does the server keep track of this by the client's ip address? (That is session key "A" belongs to client xx.xxx.xx.xx) If yes, couldn't my ip address be same as other people who use the same isp and live in my vicinity?
Does the server instead use both ip address and port number to keep track of the
client? If so, wouldn't the port number change for every HTTP/HTTPS
request? Which would mean that the session key cannot be mapped back to the client anymore.
From what I understand SSL uses asymmetric cryptography to securely exchange a session key generated by the client, which is then used for symmetric encryption.
No, you don't understand. The session key is derived independently at both ends. It is never transmitted.
How long is this session key valid?
As long as a piece of string. It is valid until a re-handshake is performed, which can be initiated by either peer at any time.
How does the server keep track of which session key is valid for which client?
In the SSL Session.
Does the server keep track of this by the client's ip address?
No, by the session ID which is negotiated during the handshake.
(That is session key "A" belongs to client xx.xxx.xx.xx) If yes, couldn't my ip address be same as other people who use the same isp and live in my vicinity?
No. They thought of that, surprisingly enough.
Does the server instead use both ip address and port number to keep track of the
client?
No, it uses the SSL session, and also the HTTP session in the case of Web servers.
If so, wouldn't the port number change for every HTTP/HTTPS
request?
Yes, which is why they don't use it. They thought about that too.
Which would mean that the session key cannot be mapped back to the client anymore.
Which is why they don't do it. You've just invented yet another obvious vulnerability that would be obviously stupid to implement. You can stop now. They really did think about all this stuff.
Scenario: Sensitive information is exchanged (1) from client to server AND (2) from server to client.
Problem: Data exchanged is not encrypted, so sniffing is easy (it's always theoretically possible, right?)
Solution: Encrypt all data transmitted in either direction (server-to-client and client-to-server).
Implementation:
(1) Client to server - Generate certificate, install private key on server and configure Tomcat to work on HTTPS (Many tutorials for this online).
(2) Server to client - Private key goes to (or generated by) clients, however it seems that some tutorials strongly emphasize that that every client should have their own certificate for the sake of authentication.
Question: If I am already authenticating my users through a database username/password (hashed with salt) combo, but I still need to encrypt server-to-client data transmissions to reduce chance of sniffing, can I just generate one private key for all clients? Are there other ways of achieving what I need with Tomcat/Spring?
It seems you're mixing something up:
Regular https includes encryption in both directions, and only a private key + certificate on the server side. Once a client requests resources through https, they get the answer encrypted. So you'll just need to enforce the https connection (e.g. by redirecting certain requests to https with no delivery of data through http)
If you want client certificates, these are purely used for client authentication, so sharing a common client key/certificate with all possible clients will defeat this purpose. Having client keys/certs does not add any more encryption to your data transfer.
Answering to your follow-up question in the comment:
For https, the server keeps its private key, the public key is what is shared with the client. On typical https, the client can be reasonably sure who the server is (authentication, done through the trustworthy signature on the server's public key. This is what you pay trustcenters for) However, the server has no clue who the client is (here client certificates would come into play, but purely for authentication, not for encryption)
Server and client negotiate a common session key. For this purpose there are many different implementations of the key-exchange protocol. This forum is probably not the right place to describe session negotiation and the ssl handshake again, but you can be sure that you only need a server side key for the purpose you describe above: Take any website as an example: If you go to google mail, their https encryption works through them having a private key and a certified (signed) public key: You have no client side certification, but provide your username and password through the encrypted connection to them. Otherwise you'd have to install a client side key/certificate for a lot of services - and that would be too much of a burden for the average internet user.
Hope that helps.
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 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