RE: Unorthodox SSL Questions
> I do not believe there is an error in my logic. > You are using the client's trust of the Proxy > to bootstrap whether or not the client trusts > the Host with whom it is attempting to communicate > securely. If I put 'www.foo.com' in my browser, I want to make sure I reach the server owned/operated by 'www.foo.com'. I'm willing to take whatever data 'www.foo.com' sends me as I have no control over where they get the data they send me. That is the sole purpose of the certificate. 'www.foo.com' can do anything at all. It can get data from other sources I don't trust, all the certificate assures me is that whatever content I do see has been blessed by 'www.foo.com'. The proxy does not change this. The proxy *is* 'www.foo.com'. The certificate ensures me the data does come from 'www.foo.com'. I have on control over where 'www.foo.com' gets its data from, that's 'www.foo.com's job, or in this case, that's the proxy's job. > If the Proxy server becomes compromised, the Proxy > will continue to be trusted by the clients even > though all of the data exchanged between the Client > and the Host will now be visible to an attacker. Or > worse the proxy can redirect to a host which is not > even yours. *Any* host can do this. If 'www.amazon.com' becomes compromised, then anyone can see the data I see when I punch in 'https://www.amazon.com' and see a lock icon. All the certificate assures me is that 'www.amazon.com' takes responsibility for my content. > In my mind, the Client should not care one bit > about the identity of the Proxy, That's like saying I shouldn't care whether a news story was in the Sun or the New York Times. The proxy is the publisher. The publisher puts his reputation on the story. My decision to trust the story is based upon the credibility of the publisher, not the author. (An author can write stories for both the Times and the Sun, I would expect their trustworthiness to differ.) > the Proxy should > simply being acting as a packet forwarder through > which the SSL/TLS session between the Client and > the Host is negotiated. Now what I see as your > problem is that the Client (being a standard browser) > is not going to trust the certificates which you > are using for Host identification. You misunderstand. In this case, the servers are like authors, the proxies are like publishers. The job of the proxy is to validate the author's credentials. > Assuming that the Proxy has not fallen into the wrong > hands is like assuming you will never be attacked. The > point of security analysis of protocols is to determine > where the weak points are and how those weak points > could result in data compromise if they were to fail. Anything past the host is always beyond the scope of the authentication scheme. The HTTPS protocol doesn't provide any assurance other than that the content you see was 'blessed' by the host you entered in the URL. This scheme preserves that assurance. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Unorthodox SSL Questions
Marton Anka wrote: The client cannot trust the host because the client is not verifying the Host's certificate. The client has no way of knowing whether or not the proxy server has been compromised. Therefore it is not acceptable to trust the proxy to decrypt and reencrypt the data. You have now introduced a man in the middle. I think there's an error in your logic. First you state that the Client cannot trust the Host because it hasn't verified its certificate, then you go on to say that it is because it has no way of knowing whether Proxy has been compromised or not. I do not believe there is an error in my logic. You are using the client's trust of the Proxy to bootstrap whether or not the client trusts the Host with whom it is attempting to communicate securely. If the Proxy server becomes compromised, the Proxy will continue to be trusted by the clients even though all of the data exchanged between the Client and the Host will now be visible to an attacker. Or worse the proxy can redirect to a host which is not even yours. In my mind, the Client should not care one bit about the identity of the Proxy, the Proxy should simply being acting as a packet forwarder through which the SSL/TLS session between the Client and the Host is negotiated. Now what I see as your problem is that the Client (being a standard browser) is not going to trust the certificates which you are using for Host identification. I think this is two separate problems: 1. Verifying identities based on a trust chain. 2. Trusting or not trusting someone or someone's judgement by determining if they'd been compromised or not. I think 1) is solved by this process. I also think that 2) will dever be solved by anyone. Think about it this way: if Client were to connect to Host directly, it would still have no way of knowing if Host itself had been compromised or not. Of course not. However, I would hope that the security of your hosts (not being visible to the outside world) is going to be significantly better than the security of your external proxy. It all depends upon your threat model of course. SSL/TLS does not protect against host compromises. What it does protect against is the visibility and integrity of the data stream between a client and an authenticated server. If you are going to use SSL/TLS in such a way as to significantly reduce the strength of that functionality, you probably should use something other than SSL/TLS to protect your data. The first question is, is this cryptographically sound if we assume that Proxy has not fallen into the wrong hands? No. It is not a sound security process. Even if we "assume that Proxy has not fallen into the wrong hands"? Can you elaborate? There is nothing wrong with your model assuming that the client is willing to trust the proxy to protect the rest of the food chain. What you have to realize is that by making that assumption the Client really does not have any ability to trust that the data it sends really is received by the appropriate destination. Assuming that the Proxy has not fallen into the wrong hands is like assuming you will never be attacked. The point of security analysis of protocols is to determine where the weak points are and how those weak points could result in data compromise if they were to fail. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
RE: Unorthodox SSL Questions
Jeffrey, thanks for responding. > Is your goal to pay for one Verisign certificate and be able to use it for a large number of privately generated free certificates which would not be trusted by the client? No, not at all. We're not trying to save a few hundred dollars by doing this. This is just a side effect The Hosts are not visible from Client's location, Proxy has to be in the middle. > The client cannot trust the host because the client is not verifying the Host's certificate. > The client has no way of knowing whether or not the proxy server has been compromised. Therefore it is not acceptable > to trust the proxy to decrypt and reencrypt the data. You have now introduced a man in the middle. I think there's an error in your logic. First you state that the Client cannot trust the Host because it hasn't verified its certificate, then you go on to say that it is because it has no way of knowing whether Proxy has been compromised or not. I think this is two separate problems: 1. Verifying identities based on a trust chain. 2. Trusting or not trusting someone or someone's judgement by determining if they'd been compromised or not. I think 1) is solved by this process. I also think that 2) will dever be solved by anyone. Think about it this way: if Client were to connect to Host directly, it would still have no way of knowing if Host itself had been compromised or not. >> The first question is, is this cryptographically sound if we assume that Proxy has not fallen into the wrong hands? > No. It is not a sound security process. Even if we "assume that Proxy has not fallen into the wrong hands"? Can you elaborate? > I am available for consulting. You may contact me at jaltman at secure-endpoints.com for that purpose. I have been contacted by one of the OpenSSL developers and we're working on this problem, but I have emailed you at the above email address nonetheless. Thanks in advance, Marton Anka __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Unorthodox SSL Questions
Marton Anka wrote: Message Hello, I am trying to solve a very peculiar problem. In my application, there are three players: 1. Client - runs a regular web browser. 2. Proxy - runs my proxy application with OpenSSL 0.9.7c 3. Host - runs my host application with OpenSSL 0.97c Proxy accepts connections from both the Client and the Host. Proxy has a real CA certificate, therefore it is trusted by the Client and the Host. Host has an install-time generated self-signed certificate that is registered on the Proxy upon the first connection and verified upon subsequent ones. Is your goal to pay for one Verisign certificate and be able to use it for a large number of privately generated free certificates which would not be trusted by the client? Host connects to Proxy and waits. Client connects to Proxy and wishes to talk to Host. Client can verify Proxy's identity, and by trusting Proxy it can also rely on Host's identity being verified as Host needs to authenticate with a client certificate towards Proxy. The client cannot trust the host because the client is not verifying the Host's certificate. The client has no way of knowing whether or not the proxy server has been compromised. Therefore it is not acceptable to trust the proxy to decrypt and reencrypt the data. You have now introduced a man in the middle. Now Proxy can shuffle data between Client and Host. The easy way to do it is by receiving data from Client through its SSL channel, (effectively decrypting) it, and sending it to Host (re-encrypting it) through Host's SSL channel. The response comes from Host, it's decrypted/re-encrypted, and transmitted to Client. Proxy cannot simply shuffle TCP traffic, obviously, because Client, being a standard browser, does not trust Host's certificate - and even if it did, the CN would not match. The first question is, is this cryptographically sound if we assume that Proxy has not fallen into the wrong hands? No. It is not a sound security process. The second question is, can this be improved? For example, can we get rid of the decryption/re-encryption phase? Can I somehow manage to get both Host and Client to negotiate the same cipher suite and session key? I have total control over the code that runs on Proxy and Host, but Client can be any web browser. The way the client and host negotiate the same cipher suite and session key is by establishing an SSL/TLS session between the client and the host without the involvement of the proxy. Please note that I am just an ordinary SSL user and do not understand its internal workings to 100% - so I apologize if the latter question is dumb. Furthermore, if someone were willing to consult me on this matter I would, of course, be willing to pay appropirate compensation for their time. I am available for consulting. You may contact me at jaltman at secure-endpoints.com for that purpose. Thanks in advance, Marton Anka smime.p7s Description: S/MIME Cryptographic Signature
RE: Unorthodox SSL Questions
> > Question: Why the proxy? Perhaps a simple NAT router would suffice. > It's due to the nature of our application. I really can't get into details here. I have been contacted by one of the OpenSSL developers via email as a response to my yesterday's post. We're discussing this privately - but FYI, it appears that there is a solution. Thanks! Marton Anka __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Unorthodox SSL Questions
Question: Why the proxy? Perhaps a simple NAT router would suffice. On Feb 17, 2004, at 1:03 PM, Marton Anka wrote: The second question is, can this be improved? For example, can we get rid of the decryption/re-encryption phase? Can I somehow manage to get both Host and Client to negotiate the same cipher suite and session key? I have total control over the code that runs on Proxy and Host, but Client can be any web browser. Please note that I am just an ordinary SSL user and do not understand its internal workings to 100% - so I apologize if the latter question is dumb. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Unorthodox SSL Questions
Title: Message Hello, I am trying to solve a very peculiar problem. In my application, there are three players: 1. Client - runs a regular web browser. 2. Proxy - runs my proxy application with OpenSSL 0.9.7c 3. Host - runs my host application with OpenSSL 0.97c Proxy accepts connections from both the Client and the Host. Proxy has a real CA certificate, therefore it is trusted by the Client and the Host. Host has an install-time generated self-signed certificate that is registered on the Proxy upon the first connection and verified upon subsequent ones. Host connects to Proxy and waits. Client connects to Proxy and wishes to talk to Host. Client can verify Proxy's identity, and by trusting Proxy it can also rely on Host's identity being verified as Host needs to authenticate with a client certificate towards Proxy. Now Proxy can shuffle data between Client and Host. The easy way to do it is by receiving data from Client through its SSL channel, (effectively decrypting) it, and sending it to Host (re-encrypting it) through Host's SSL channel. The response comes from Host, it's decrypted/re-encrypted, and transmitted to Client. Proxy cannot simply shuffle TCP traffic, obviously, because Client, being a standard browser, does not trust Host's certificate - and even if it did, the CN would not match. The first question is, is this cryptographically sound if we assume that Proxy has not fallen into the wrong hands? The second question is, can this be improved? For example, can we get rid of the decryption/re-encryption phase? Can I somehow manage to get both Host and Client to negotiate the same cipher suite and session key? I have total control over the code that runs on Proxy and Host, but Client can be any web browser. Please note that I am just an ordinary SSL user and do not understand its internal workings to 100% - so I apologize if the latter question is dumb. Furthermore, if someone were willing to consult me on this matter I would, of course, be willing to pay appropirate compensation for their time. Thanks in advance, Marton Anka
