it seams that, if using HTTPS protocol, packages transferred between browser and web server are all encrypted. And all the browser has to support its communication session with web server is so called certificates.
So I think it's clear that we can use the same certificates to decrypt packages that captured by Wireshark during the login of HTTPS sites.
I googled, and find some tutorials said the private key should be supplied, which i do think impossible and unpractical.
BTW. the following shell command get certificate from host , are there tools to yield the public key?
echo QUIT | openssl s_client -connect <site>:443 | sed -ne '/BEGIN CERT/,/END CERT/p'
Thanks in advance.
No, you cannot decrypt HTTPS/SSL sessions from a network capture, even if you do have the certificates. That is the whole point of Public Key Cryptography on which SSL is based.
What you have in your browser key-store is the certificates that will verify the validity of the public keys of the server. Said public keys are accessible, but they cannot be used to decrypt the session packets because the encryption algorithm is not symmetric.
You would need the private keys of the server in order to descrypt an SSL session and in normal situations it is quite hard to acquire those.
See also the Wikipedia article on TLS for more information.
EDIT:
I will add some more information in layman terms, mostly ripped off from the two links above, to make things a bit more clear.
Public Key Cryptography is based on asymmetric encryption algorithms. Those involve two keys, rather than one, a public key and a private key. Those two keys consist a key pair. Assuming a sufficiently strong algorithm, whatever is encrypted with the public key can only be encrypted with the private one and vice versa. The public key is widely accessible to "everyone" while the private key is stored securely and only used by its owner. How does this help?
The server has a key pair that consists of a world-readable public key and a securely stored (and inaccessible to anyone but the server itself) private key.
The client uses the server's public key to encrypt a rather long random key for a symmetric algorithm at the start of each encrypted session. That key is sent to the server.
Since the symmetric key is encrypted like this, it can only be decrypted using the server's private key. That means that it cannot be extracted from a captured network stream, and since it is used for the rest of the session, neither can any of the information that is transmitted later on.
The server uses its private key to retrieve the session symmetric key and all is well.
Is it? There is still one issue in the above scheme! How will the client get the server's public key? More specifically how does it know that it speaks with the server proper, and not some crook who managed to insert themselves in the middle (See Man In The Middle attack)?
The client cannot possibly know every single public key - there are millions of them. It will have to retrieve them from the servers and then somehow make sure they belong to the server they are interested in.
This is where another function of Public Key Cryptography comes in. Previously we used the public key to encrypt data so that only its intended destination could descrypt it. Now we
do the opposite: We use the private key to encrypt data so that it can only be decrypted with the public key. Essentially we sign the data so that if decrypts with the public key people will know the data came from the server. How does this help?
When the browser is installed it has a relatively small number of public keys (commonly known as certificates) pre-installed. Those belong to Certification Authorities (CA) that are entities (generally companies like Verisign, governments or even some Institutions) that are deemed trustworthy. The Certification Authorities use the corresponding private keys to sign other public keys available in the Internet and so on.
So when the browser contacts a server and receives its public key, that key should be signed with the private key from a certificate pair. That certificate pair would be likewise be signed by another and so on, until the browser comes up to a public key that was signed with the private key that corresponds to one of the Root Certificates that were preinstalled with it. You might want to read a previous answer of mine for more on Root Certificates, or just read the Wikipedia articles.
Since each public key was successively signed until we reached a trusted key, the client can now be certain that the server on the other end of the connection is indeed e.g. MyBank.com and not, say, some criminal's laptop in the next cafe table that is messing with the wireless connection.
While there have been weak SSL algorithms (hence the succession of SSL protocol versions), these days the attacks are generally targeted to the implementations:
Use specially crafted or malformed certificates to fool the browser (and its weak implementation) into thinking that a public key is signed by a trusted entity when it's really not.
Compromise the integrity of the client software (e.g. a virus) to capture the symmetric keys when they are generated. In most of those cases however, it is usually easier to just capture the interesting data as they are entered into the browser by e.g. capturing the keyboard strokes as the user types in their credit card number.
Compromise the server itself and steal the private key. While it's not as easy as targeting unsuspecting clients, it has happened and it has the potential to compromise a significantly larger number of encrypted sessions. The current Public Key Infrastructure (PKI) has a whole mechanism for the revocation and disabling of compromised or otherwise invalid keys.
The last attack can be defeated if the client sends a temporary public key of its own instead of a symmetric key and use an asymmetric algorithm for the whole session. That would make it impossible for an attacker to compromise past sessions by stealing the server's private key. This technique is the basis for ensuring Perfect Forward Secrecy, but unfortunately not all servers implement it yet due to compatibility or performance reasons.
thkala is spot on. You can, assuming you have MiTM, under common circumstances forward a self signed certificate to the victim for which you have the private key, then forward the requests by the victim to the destination server using the servers' real certificate. This will require the vicitm to accept a certificate warning though.
Another way of defeating Ssl is by stripping the ssl session, lookup sslstrip.
Related
I am a developer with very little experience of encryption. I am trying to learn more about Encryption and specifically SSL in my spare time.
Say a trusted company has a file (notepad) that contains a load of personal and confidential information. Say I wanted to ask them to send this information to a me to analyze. How would I do this?
My research is telling me that I would have to:
1) Create a self signed certificate
2) Generate the public and private key
3) Issue the public key to the trusted company and keep the private key
4) Ask the company to encrypt the information using the public key and then send it to me
5) Decrypt the file using the private key
Is that correct? How would I do this?
Should the certificate be signed by a Certificate Authority in this case as I would manually be issuing the public key to the trusted company (they know it comes from me).
As I said I am relatively new to this subject.
SSL is a protocol for encrypting network connections. It's not really relevant for manually encrypting and decrypting files. (It's also insecure and deprecated; TLS should be used instead.)
If you want to manually encrypt and decrypt files, yes, you could use a self-signed certificate and just give the public key to the company that'll send the file. However, you have to make sure to give them the public key in a way that can't be intercepted — such as physically handing it over on a flash drive, not emailing it — or you're vulnerable to a man-in-the-middle attack: someone could intercept the public key and give the company a different one instead. (If that happened, the company would unknowingly be encrypting the file for the attacker to decrypt, and the attacker would then re-encrypt the file with the real public key and send it along to you.)
If you're doing this manually and you deliver the public key in a secure way, you don't need to involve a certificate authority. The purpose of a certificate authority is to vouch for the authenticity of a certificate when it's delivered over an insecure channel. For example, when you visit stackoverflow.com, your browser gets a certificate (with a public key) from the web server. Since this certificate wasn't personally given to you by SO staff, how do you know that the web server is the real stackoverflow.com, not a man-in-the-middle attacker intercepting your connection in order to hijack your account? The website's certificate is signed by a certificate authority — DigiCert, currently — that says DigiCert has verified that it's real. Your browser is configured to trust that signature from DigiCert, because the browser developers have verified that the company is trustworthy.
PGP and GPG are good tools for securely exchanging encrypted files. They use a "web-of-trust" model based on securely exchanging certificates, rather than relying on a certificate authority.
I am looking for a way to encrypt messages between client and server using the WCF. WCF offers a lot of built in security mechanisms to enrcypt traffic between client and server, but there seems to be nothing fitting my requirements.
I don't want to use certificates since they are too complicated, so don't suggest me to to use certificates please. I don't need confidentiality, so I though I'll go best using plain RSA.
I want real security, no hardcoded key or something. I was thinking about having a public/private keypair generated every time the server starts. Both keys will only be stored in RAM.
Then wen a client connects it should do exactly like SSL. Just as described here.
1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
2.using that private/public key pair, exchange a common shared secret, e.g. an "encryption key" that will symmetrically encrypt your messages (and since it's symmetrical, the server can use the same key to decrypt the messages)
3.setup infrastructure on your client (e.g. a WCF extension called a behavior) to inspect the message before it goes out and encrypt it with your shared secret
That would be secure, wouldn't it?
Is there any existing solution to archive what I described? If not I'll create it on my own. Where do I start best? Which kind of WCF custom behaviour is the best to implement?
EDIT:
As this is NOT secure, I'll take the following approach:
When Installing the server component a new X509 certificate will be generated and automatially added to the cert store (of the server). The public part of this generated certificate will be dynamically included into the client setup. When running the client setup on the client machine the certificate will be installed into the trustet windows certificate store of the client.
So there's no extra work when installing the product and everything should be secure, just as we want it.
You've said you don't want to use certificates. I won't push certificate use on you, but one thing you are missing is that certificates serve a purpose.
A certificate proves that key you are negotiating an SSL connection with belongs to the entity you think it belongs to. If you have some way of ensuring this is the case without using certificates, by all means, use raw keys.
The problem is, in step 1:
1.exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
How does the client know that the public key it received from the server wasn't intercepted by a man-in-the-middle and replaced with the MITM's key?
This is why certificates exist. If you don't want to use them, you have to come up with another way of solving this problem.
Do you have a small, well-known set of clients? Is it possible to preconfigure the server's public key on the client?
Alexandru Lungu has created an article on codeproject:
WCF Client Server Application with Custom Authentication, Authorization, Encryption and Compression
No, it would not be secure!
since there's no confidentiality, an attacker could do a men in the middle attack, and all the security is gone.
The only real secure way of encrypting messages between server and client IS to actually use digital certificates.
I'm sorry, the only two methods of providing secure communications are:
Use a public key infrastructure that includes a chain of trust relationships, a.k.a. certificates
or
Use a shared secret, a.k.a. a hardcoded key.
Nothing else addresses all of the known common attack vectors such as man-in-the-middle, replay attack, etc. That's the hard truth.
On the other hand I can offer you an alternative that may alleviate your problem somewhat: Use both.
Write a very, very simple web service whose only job is to generate symmetric keys. Publish this service via SSL. Require end user credential authentication in order to obtain a symmetric key.
Write the rest of your services without SSL but using the symmetric keys published via the first service.
That way your main app doesn't have to deal with the certificates.
Isn't it possible to simply capture the key while it's being negotiated between machines?
Let's say I connect to my bank's website. Browser will send request to bank server. Bank server will send me copy of its SSL certificate. If it's valid, browser will send signed ack. Isn't it possible to simply capture private key at that time?
Your private key (and bank's too) is never sent over the network. The bank's public key is a part of the X509 certificate that it sends to your browser. If banks signs anything it does it using its private key, and your browser verifies the signature using the bank's public key (from the certificate). The whole SSL session is encrypted using symmetric cipher (for performance reasons). To be able to do that both parties need to exchange the session key (different for each connection and renegotiated after defined interval of time). This exchange is done using Diffie-Hellman algorithm. During this exchange the key is not sent over the network, it is computed independently by both parties.
Isn't it possible to simply capture the key while it's being
negotiated between machines?
No because it is never sent, it is computed independently. You would need the server's private key, which is private, to repeat the independent computations that lead to the session key. So it is secure.
Only public key is shared. The bank dosen't need to share the private one.
Private key is not shared and is not stored in the cert.
I was looking into SSL and some of the steps that are involved to set up an encrypted connection between a server and a client computer.
I understand that a server key and certificate is sent to the browser, and that a secret code is being calculated, like they say in the following video:
http://www.youtube.com/watch?v=iQsKdtjwtYI
around 5:22, they talk about a master secret code that is being calculated to start talking in an encrypted way.
My question now is: before the connection is actually encrypted (the handshake phase), all communication between the server and the client can be sniffed by a packet sniffer. Isn't it then possible to sniff the encryption key or other data that is used to set up a secure connection?
From the Wikipedia summary, I think the key part you're interested in is:
The client responds with a ClientKeyExchange message, which may
contain a PreMasterSecret, public key, or nothing. (Again, this
depends on the selected cipher.) This PreMasterSecret is encrypted
using the public key of the server certificate.
This is why the public key is so important. If you use the wrong public key, you're vulnerable to man in middle attacks.
Witness the justified worry whenever bogus SSL certificate issues (e.g. DigiNotar).
The secret key itself isn't transmitted at all, so it can't be sniffed. It is computed independently at both ends. The materials it is computed from is called a PreMasterSecret which is encrypted with the public key of the server certificate. So unless the server's private key has been compromised the secret key can be neither sniffed nor calculated independently.
This question already has answers here:
How does browser generate symmetric key during SSL handshake
(2 answers)
Closed 2 years ago.
I have been reading on HTTPS, trying to figure out how exactly it works. To me it doesn't seem to make sense, for example, I was reading this
https://ssl.trustwave.com/support/support-how-ssl-works.php
And notice it says this in the page
Step 4: xyz.com will next create a
unique hash and encrypt it using both
the customer's public key and
xyz.com's private key, and send this
back to the client.
Step 5: Customer's browser will decrypt the hash. This process shows
that the xyz.com sent the hash and
only the customer is able to read it.
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can?
Thanks for any response
Why is HTTPS required?
To verify whether the website is authenticated/certified or not (uncertified websites can do evil things). An authenticated website has a unique personal certificate purchased from one of the CA’s.
Who are CA’s (Certificate Authorities)?
CA’s are globally trusted companies like GoDaddy, GeoTrust, VeriSign etc who provide digital certificates to the websites.
What are public keys and private keys?
Keys are nothing but long random numbers used to encrypt/decrypt data.
Public keys are keys which can be shared with others. Private keys are meant to be kept private.
Suppose Jerry generates a private key and public key. He makes many copies of that public key and shares with others.
Now, others can only encrypt the data using the public key and that data can only be decrypted by the private key of Jerry.
Another approach is to use public keys to only decrypt the data and private keys to only encrypt the data.
How does a company get a certificate?
Website owner first generates a public key and private key, keeping the private key secret.
He gives a Certificate Signing Request file (CSR) and his public key to the CA.
CA then creates a personal certificate based on CSR including domain name, owner name, expiry date, serial no. etc and also adds an encrypted text (= digital signature) to the certificate and finally encrypts the whole certificate with the public key of the server and sends it back to the website owner.
This certificate is then decrypted with the private key of the website owner and finally, he installs it on the website.
Note: That encrypted text is the digital signature of the CA. That
text is encrypted by the private key of the CA and can only be
decrypted by a public key of CA.
When you install your operating
system or Browser, root-certificates from many trusted CA's like
GeoTrust, VeriSign, GoDaddy etc. come with it. These root-certificates
contain the public key of that CA provider which helps decrypt the
signature.
HTTPS security can be split into 2 parts (Handshakes):
1. To validate the certificate of a website:
1) When you enter the URL www.Google.com, Google’s server gives its public key and certificate (which was signed by GeoTrust) to the Browser.
2) Now browser has to verify the authenticity of the certificate i.e. it’s actually signed from GeoTrust or not.
As browsers come with a pre-installed list of public keys from all the major CA’s, it picks the public key of the GeoTrust and tries to decrypt the digital signature of the certificate which was encrypted by the private key of GeoTrust.
3) If it’s able to decrypt the signature (which means it’s a trustworthy website) then it proceeds to the next step else it stops and shows a red cross before the URL.
2. To create a secure connection (encrypts outgoing and incoming data) so that no one else can read it:
1) As I mentioned, Google sends its public key when you enter www.Google.com . Any data encrypted with this public key can only be decrypted by Google’s private key which Google doesn’t share with anyone.
2) After validating the certificate, browser creates a new key let’s call it Session Key and make 2 copies of it. These keys can encrypt as well as decrypt the data.
3) The browser then encrypts (1 copy of session key + other request data) with the Google's public key . Then it sends it back to the Google server.
4) Google’s server decrypts the encrypted data using its private key and gets the session key , and other request data.
Now, see, server and browser both have got the same copies of session
key of the browser. No one else has this key, therefore, only server
and browser can encrypt and decrypt the data. This key will now be
used for both to decrypt and to encrypt the data.
5) When Google sends the data like requested HTML document and other HTTP data to the browser it first encrypts the data with this session key and browser decrypts the data with the other copy of the session key.
6) Similarly, when browser sends the data to the Google server it encrypts it with the session key which server decrypts on the other side.
Note: This session key is only used for that session only. If the user
closes the website and opens again, a new session key would be
created.
can't get enough of web? behind the scenes when u type www.google.com in browser
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.
First, understand that there are generally two steps of HTTPs communication.
1) Generate a shared symmetric key which can only be known between client and server, no one else knows it
2) With this shared symmetric key, client and server is able to safely communicate with each other without worrying about information being intercepted and decrypted by others.
So the question becomes, how can the client and server generate a secret shared key without being known by others in this open internet? This is the asymmetric algorithm coming to play, a demo flow is like below:
-- Client receives public key from server.
-- Client generates a key string "DummySharedKey" which will be later used as shared key, and encrypt it into "7$&^^%####LDD!!#" with server's public key, Man-in-the-middle may have the public key and might be able to intercept the encrypted data, but the data is useless to him as the data can only be decrypted by sever's private key.
-- Server receives the encrypted key string "7$&^^%####LDD!!#", and decrypt it into "DummySharedKey" with its private key
Above key exchange steps makes sure that only Client and Server can know the shared key is "DummySharedKey", no one else knows it.
So it's critical to understand that it is Client's responsibility to generate the shared key, NOT SERVER! (i think this is what confused you)
I also recommend you to take a look at this video which explains HTTPs very well.
https://www.youtube.com/watch?v=JCvPnwpWVUQ&list=FLt15cp4Q09BpKVUryBOg2hQ&index=3
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.
Public/private key encryption is based on modulo arithmetics using prime numbers.
Such asymmetric encryption was only discovered in the mid-1970s. It is credited to Diffie and Hellman, and to Rivest, Shamir and Adleman. (Though, both actually rediscovered things already known by the British secret services.)
The wikipedia page on Diffie-Hellman has a detailed example of a secret key exchange through a public channel. While it does not describe SSL itself, it should be handy to make sense of why knowing a public key doesn't reveal the contents of a message.
You might also find this simple RSA example interesting.
I'm studying related topics and read several blogs like how-https-works and how-does-https-work-rsa-encryption-explained/.
I have summarized a sequence diagram based on my study and hope it can be helpful to someone who comes to this thread.
For more details, you can check the blog mentioned.
I have written a small blog post around SSL Handshake between the server/client. Please feel free to take a look.
SSL Handshake
A small snippet from the same is as follows:
"Client makes a request to the server over HTTPS. Server sends a copy of its SSL certificate + public key. After verifying the identity of the server with its local trusted CA store, client generates a secret session key, encrypts it using the server's public key and sends it. Server decrypts the secret session key using its private key and sends an acknowledgment to the client. Secure channel established."
It also describes the symmetric/asymmetric encryption which is used for SSL certificates and data transfer once secure transport is established.
For detailed explanation of SSL, see https://www.ietf.org/rfc/rfc2246.txt
Here are the brief ideas of SSL to answer your question:
1) Using certificates to authenticate. Server certificate is a must and client certificate is optional (only when the server requests it). A certificate is like something to prove who you are and it also contains a public key for asymmetric encryption.
2) Using asymmetric encryption (with public key in the server certificate) to establish a shared symmetric key which is used to transfer data between client and server securely by symmetric encryption (for performance reason because symmetric encryption is faster than asymmetric encryption).
The shared symmetric key is established by exchanging a premaster secret from client side (encrypted with server public key) and is derived from the pre-master secret together with client random and server random (thanks #EJP for pointing this out in the comment):
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
We need the server random and client random to prevent replay attacks that an attacker can capture the previous session and replay it for the new session.
What I don't understand is, couldn't a hacker just intercept the
public key it sends back to the "customer's browser", and be able to
decrypt anything the customer can.
The hacker cannot decrypt the message since he does not know the server private key. Be aware that public key cannot be used to decrypt the message.