-3

I have gone thru two good links about HTTP Vs HTTPS i.e

  1. http://en.wikipedia.org/wiki/HTTP_Secure
  2. http://answers.yahoo.com/question/index?qid=20070604161212AAsnSFX

I have come up with my simple understanding and some queries.Here is the understanding :-

  1. As we move to https from http we have to modify the web-application so that as it receives the first request, it sends the digital certificate with the response.

  2. The other thing we have to modify is server.xml to include keystore location(like value is .keystore) and password. This keystore will actually contain the key that will be used to encrypt and decrypt the data on both the sides i.e server and client(browser).

  3. Now when client sends the first request it gets the encryped data, certificate and key. On the basis of this key , browser decrypt the data and encrypt again to send it back to client. Once browser accepts checks the authenticity of certificate, it gives clearance saying it is trusted site.

Are the steps above correct?

If yes, how come we can say hackers can break this. Because if encryption and decryption is happening on the basis algorithm(based on key liying in .keystore file), they can also decrypt the data when the request is being sent to server. If browser can that algorith why not hackers? I agree it will add one extra security step but still it can be hacked. Just a thought?

kleopatra
  • 51,061
  • 28
  • 99
  • 211
M Sach
  • 33,416
  • 76
  • 221
  • 314

2 Answers2

0

I don't quite follow your question, but yes, it is possible to eavesdrop on HTTPS provided that you can intercept the messages in both directions - have a read about man-in-the middle attacks.

However, if public keys can be securely exchanged "out-of-band" or otherwise verified, then public-key crypto is secure against eavesdropping.

DNA
  • 42,007
  • 12
  • 107
  • 146
  • 1
    This works only if you have a valid certificate for the targeted server (or the client explicitly accepts a non-valid one) – Jens Schauder Mar 06 '12 at 11:47
  • Yes, agreed; the limitation is obtaining, or issuing a certificate that the client will accept. – DNA Mar 06 '12 at 11:53
0

The rough basics are as follows:

The server has a public and a private key. Everything that is encrypted with one can only be decrypted with the other.

On a request the server sends the public key.

The client creates a secret (think random number), encrypts it with the public key and sends it back.

Only the server can decrypt it.

Server and Client now share a secret which they can use to encrypt messages going back and forth.

If you want more details about this I recommend to google SSL

Jens Schauder
  • 77,657
  • 34
  • 181
  • 348
  • actually i have doubts about two files. I can two key files one .keystore and another is CAKey.pem. I specifically want to know the difference between these two files. In server.xml i find a entry of .keystore file and password against it while in application i find a password which i had given for CAKey.pem. So got confused between these two files and roles – M Sach Mar 06 '12 at 11:59
  • That is a completely different question (not at all about the workings of HTTPS) but about the purpose of certain specific file formats. Go ahead, make it a question on stackoverflow – Jens Schauder Mar 06 '12 at 12:09
  • http://stackoverflow.com/questions/9586304/role-of-files-keystore-and-cakey-pem-in-ssl – M Sach Mar 06 '12 at 16:14