Why DNS/IP in certificate?
Why should one include the DNS/IP of oneself in a certificate? Consider A connecting to B. B exposes a certificate from a trusted CA to A. Now C tries to impersonate B. It easily finds B's certificate, and somehow manages to redirect or intercept the connection request from A. It responds with B's certificate, and so connection is established. HOWEVER: Since C does not have B's private key, it is unable to sign data, or decrypt data. Thus it cannot inflict damage? What am I missing? Also, do OpenSSL automatically renegotiate symmetric keys every X minutes (or Y bytes)? Regards, Jan __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Why DNS/IP in certificate?
Yes, but that also means that there is no security benefit in storing a DNS name/IP address within the certificate. It is simply redundant, no? /Jan On Thu, 2002-01-10 at 15:09, Neff Robert A wrote: > No, you misunderstand the handshake. B cannot be impersonated by C > because C does not have the private key associated with the public > key contained within B's certificate and thus cannot present that > cert to successfully establish an SSL connection... > > -Original Message- > From: Jan Vittrup Hansen [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 8:41 AM > To: [EMAIL PROTECTED] > Subject: Why DNS/IP in certificate? > > > Why should one include the DNS/IP of oneself in a certificate? > > Consider A connecting to B. > > B exposes a certificate from a trusted CA to A. > > Now C tries to impersonate B. It easily finds B's certificate, > and somehow manages to redirect or intercept the connection request from > A. > > It responds with B's certificate, and so connection is established. > HOWEVER: Since C does not have B's private key, it is unable to sign > data, or decrypt data. Thus it cannot inflict damage? What am I missing? > > Also, do OpenSSL automatically renegotiate symmetric keys every X > minutes (or Y bytes)? > > Regards, Jan > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > * > DISCLAIMER: The information contained in this e-mail may be confidential > and is intended solely for the use of the named addressee. Access, copying > or re-use of the e-mail or any information contained therein by any other > person is not authorized. If you are not the intended recipient please > notify us immediately by returning the e-mail to the originator. > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Why DNS/IP in certificate?
> Also, do OpenSSL automatically renegotiate symmetric keys every X > minutes (or Y bytes)? Automatically via the SSL_BIO (providing you specify time or byte thresholds) or manually via SSL_renegotiate. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Why DNS/IP in certificate?
I am afraid I still do not quite understand, perhaps because we are talking about different scenarios. In my case I am also the CA. I therefor have absolute trust in the privatekey/certificate issued to both A and B - I do not need to proove to e.g. verisign that I control a given URL. Note that I am not just nit-picking - I am dealing with clients who (physically) cannot reveal a unique IP or DNS name, as they may be hidden behind NAT firewalls at arbitrary IP's, so please bear with me =o) Now, following your example, assume that A connects to C on www.someothersite.com, which identifies itself using B's certificate. It is certainly true that I can avoid the connection simply by looking at the CN of the certificate versus the DNS, BUT as I understand it, no damage can occur if accept the connection as C does not have the private key of B, and so cannot sign data, and thus THEN refuse the connection. In this case, does the assumption of absolute trust in the CA change the need for the DNS name in the CN? /Jan On Thu, 2002-01-10 at 15:34, Neff Robert A wrote: > > The client needs to verify who it is connected to. > Anyone in the world can present a certificate to > establish an ssl connection. In a nutshell, the > checks that need to be made on the client end are: > a. Do you trust the signer of the certificate received > b. Is the CN contained within the cert what you expect > > For example, I can easily create a certificate that > contains the CN www.vittrup-hansen.dk. However, I cannot > get Verisign to sign that certificate. That is the base > of trust. > > If OpenSSL is configured to verify the certificate chain > using the cert store during a connection attempt, and that > connection completes successfully, you are assured of the > receipt of a trusted cert. At this point you only know that > you are connected to a site that sent a certificate signed > by a trusted CA. Your next task is to ensure that the > trusted cert truly came from the site you expected and > not www.someothersite.com. The browser does this step by > comparing the CN contained in the cert to the URL address > typed into your browser. Your own app must do so as well... > > > -Original Message- > From: Jan Vittrup Hansen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 10, 2002 9:13 AM > To: Neff Robert A > Cc: '[EMAIL PROTECTED]' > Subject: RE: Why DNS/IP in certificate? > > > Yes, but that also means that there is no security benefit in storing a > DNS name/IP address within the certificate. It is simply redundant, no? > > /Jan > > On Thu, 2002-01-10 at 15:09, Neff Robert A wrote: > > No, you misunderstand the handshake. B cannot be impersonated by C > > because C does not have the private key associated with the public > > key contained within B's certificate and thus cannot present that > > cert to successfully establish an SSL connection... > > > > -----Original Message- > > From: Jan Vittrup Hansen [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, January 09, 2002 8:41 AM > > To: [EMAIL PROTECTED] > > Subject: Why DNS/IP in certificate? > > > > > > Why should one include the DNS/IP of oneself in a certificate? > > > > Consider A connecting to B. > > > > B exposes a certificate from a trusted CA to A. > > > > Now C tries to impersonate B. It easily finds B's certificate, > > and somehow manages to redirect or intercept the connection request from > > A. > > > > It responds with B's certificate, and so connection is established. > > HOWEVER: Since C does not have B's private key, it is unable to sign > > data, or decrypt data. Thus it cannot inflict damage? What am I missing? > > > > Also, do OpenSSL automatically renegotiate symmetric keys every X > > minutes (or Y bytes)? > > > > Regards, Jan > > > > __ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List[EMAIL PROTECTED] > > Automated List Manager [EMAIL PROTECTED] > > * > > DISCLAIMER: The information contained in this e-mail may be confidential > > and is intended solely for the use of the named addressee. Access, > copying > > or re-use of the e-mail or any information contained therein by any other > > person is not authorized. If you are not the intended recipient please > > notify us immediately by returning the e-mail to the originator. > > > > **
Re: Why DNS/IP in certificate?
If the DNS is not present as CN, the certificate simply states that the CA (that I trust) did issue the private key to corresponding to the public key contained within the certificate. And since the private key is needed for signing and decryption, is this not security enough for data transfer? /Jan On Thu, 2002-01-10 at 15:58, Rich Salz wrote: > Jan Vittrup Hansen wrote: > > > Why should one include the DNS/IP of oneself in a certificate? > > It provides a convenient "hook" for a client to map the server > certificate to the server it is connecting to. The certificate says > "this is the keypair for foo.bar.com". If the DNS is not in the name, > what is the certificate saying? > /r$ > > -- > Zolera Systems, http://www.zolera.com > Information Integrity, XML Security > > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Why DNS/IP in certificate?
Thank your reply and patience =o) - this *something* is the public key within the certificate. As I see it, the information is already present through the correlation between the public and private key. As of yet there has been no response to this point: Is it not true that although I may connect to someone with with a copy of a certificate containing only a public key, they can do nothing (can't sign), and understand nothing (can't decrypt), as they do not possess the private key. Is this not true? This is the point I am trying to understand. If it is not true, then why? How do they send data with correct signatures? How is the data decrypted at their end? If this is true I need no unique ID such as DNS, I simply require a response from the peer, and close connections if data signatures do not match. Am I wrong? Regards, Jan On Thu, 2002-01-10 at 17:51, Rich Salz wrote: > Sorry I was not clear enough. > > I connect to www.foo.com over SSL, and everything validates. The > server's certificate says "joe" in the DN. > > How do I know that joe is "www.foo.com"? There must be *something* in > the certificate that identifies the host. > /r$ > -- > Zolera Systems, http://www.zolera.com > Information Integrity, XML Security > > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Why DNS/IP in certificate?
It depends on what you need. All you know in that case is that the certificate you have is one of the you do not know how many certificates signed by the CA. If all you are doing is providing blind authorization to all members of a group, that is enough. However, if you are doing pretty much any else, you need to be able to determine if the certificate you received belongs to the entity you are expecting to communicate with. > If the DNS is not present as CN, the certificate simply states that the > CA (that I trust) did issue the private key to corresponding to the > public key contained within the certificate. And since the private key > is needed for signing and decryption, is this not security enough for > data transfer? > > /Jan Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Why DNS/IP in certificate?
Deear Ladies and Gentlemen, I am writing to thank you for your comments about this matter and ask On Thu, Jan 10, 2002 at 09:34:50AM -0500, Neff Robert A wrote: > > The client needs to verify who it is connected to. > Anyone in the world can present a certificate to > establish an ssl connection. In a nutshell, the > checks that need to be made on the client end are: > a. Do you trust the signer of the certificate received > b. Is the CN contained within the cert what you expect > ..snip.. > Your next task is to ensure that the > trusted cert truly came from the site you expected and > not www.someothersite.com. The browser does this step by > comparing the CN contained in the cert to the URL address > typed into your browser. Your own app must do so as well... > is it possible to have an OpenSSL server located behind a Network Adress Transalation device (a NET device is sometimes part of firewalls, eg the Cisco PIX) and still have the client handshake complete without error ? Here is the scenario. Server has valid certificate signed by root CA for Distinguished Name 'S'. DNS responds to an A record request from the client for S, with the public interface of the NAT device (PTR query for that address also returns S), but the OpenSSL server with that cert has a completely different address (because its been translated) One might do this because of outsourcing or merger activities that result in a new or different firewall. Presumably the network between the NAT box and the OpenSSL server is secure enough to be tolerablee. So :- 1 Will the scenario above work ? 2 If not, how can it be made to work ? Thank you, Yours sincerely. -- Stanley Hopcroft Network Specialist '...No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friend's or of thine own were. Any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee...' from Meditation 17, J Donne. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Why DNS/IP in certificate?
Personally I would have a second server outside the NAT device that proxies requests in and out of the server behind the firewall. There seems to me little point in having a firewall if you allow public access straight through it! In that case you can secure the connection between the outside machine and the client machine without worrying about the firewall. - John Airey Internet systems support officer, ITCSD, Royal National Institute for the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] Agnostic (Greek) = Ignoramus (Latin) >-Original Message- >From: Stanley Hopcroft [mailto:[EMAIL PROTECTED]] >Sent: 14 January 2002 09:36 >To: [EMAIL PROTECTED] >Subject: Re: Why DNS/IP in certificate? > > >Deear Ladies and Gentlemen, > >I am writing to thank you for your comments about this matter and ask > >On Thu, Jan 10, 2002 at 09:34:50AM -0500, Neff Robert A wrote: >> >> The client needs to verify who it is connected to. >> Anyone in the world can present a certificate to >> establish an ssl connection. In a nutshell, the >> checks that need to be made on the client end are: >> a. Do you trust the signer of the certificate received >> b. Is the CN contained within the cert what you expect >> > >..snip.. > >> Your next task is to ensure that the >> trusted cert truly came from the site you expected and >> not www.someothersite.com. The browser does this step by >> comparing the CN contained in the cert to the URL address >> typed into your browser. Your own app must do so as well... >> > >is it possible to have an OpenSSL server located behind a >Network Adress >Transalation device (a NET device is sometimes part of firewalls, eg >the Cisco PIX) and still have the client handshake complete without >error ? > >Here is the scenario. > >Server has valid certificate signed by root CA for Distinguished Name >'S'. > >DNS responds to an A record request from the client for S, with the >public interface of the NAT device (PTR query for that address also >returns S), but the OpenSSL server with that cert has a completely >different address (because its been translated) > >One might do this because of outsourcing or merger activities that >result in a new or different firewall. > >Presumably the network between the NAT box and the OpenSSL server is >secure enough to be tolerablee. > >So :- > >1 Will the scenario above work ? >2 If not, how can it be made to work ? > >Thank you, > >Yours sincerely. > >-- >--- >- >Stanley Hopcroft Network >Specialist >--- >- > >'...No man is an island, entire of itself; every man is a piece of the >continent, a part of the main. If a clod be washed away by the sea, >Europe is the less, as well as if a promontory were, as well as if a >manor of thy friend's or of thine own were. Any man's death diminishes >me, because I am involved in mankind; and therefore never send to know >for whom the bell tolls; it tolls for thee...' > >from Meditation 17, J Donne. >__ >OpenSSL Project http://www.openssl.org >User Support Mailing List[EMAIL PROTECTED] >Automated List Manager [EMAIL PROTECTED] > - NOTICE: The information contained in this email and any attachments is confidential and may be legally privileged. If you are not the intended recipient you are hereby notified that you must not use, disclose, distribute, copy, print or rely on this email's content. If you are not the intended recipient, please notify the sender immediately and then delete the email and any attachments from your system. RNIB has made strenuous efforts to ensure that emails and any attachments generated by its staff are free from viruses. However, it cannot accept any responsibility for any viruses which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Why DNS/IP in certificate?
>is it possible to have an OpenSSL server located behind a Network Adress >Transalation device (a NET device is sometimes part of firewalls, eg >the Cisco PIX) and still have the client handshake complete without >error ? Yes, you can use NAT devices quite easily since they really are just a simple form of proxy to your backend server. The server would still contain your designated DN within the certificate. As a side note: A problem that can occur with that scenario is load balancing. If your site performs heavy back-end dynamic processing you will need to research products that will help you in this regard. [snip] >One might do this because of outsourcing or merger activities that >result in a new or different firewall. One also does this to own/rent one Internet IP address only from your local ISP. This is also to prevent making multiple internal IP address available to the Internet. ;-) >Presumably the network between the NAT box and the OpenSSL server is >secure enough to be tolerablee. It wouldn't matter since the SSL connection was between the client and the server. You would still have encrypted data all the way through (unless your NAT device is capable of doing something like converting HTTPS to HTTP for your backend. Then you might worry... >So :- >1 Will the scenario above work ? Yes >2 If not, how can it be made to work ? >Thank you, Your Welcome, Rob * DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Why DNS/IP in certificate?
A good example of a NAT device would be the Linksys Cable/DSL router. This device is perfect for a small office that needs connection to the Internet and provides hardware firewall protection by limiting the IP addresses and ports that are forwarded on to backend servers. It has multiple hardware ports to build a nice sized network with. I personally own this and highly recommend this product. And no, I don't get kickbacks from them! :-) Also, the debate of how to properly configure your network from a security perspective can have religious overtones! ;-) There is more to security than add two parts firewall, one part proxy, 3 parts SSL, one part virus-scanner, mix well... Cheers, Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 9:35 AM To: [EMAIL PROTECTED] Subject: RE: Why DNS/IP in certificate? Personally I would have a second server outside the NAT device that proxies requests in and out of the server behind the firewall. There seems to me little point in having a firewall if you allow public access straight through it! In that case you can secure the connection between the outside machine and the client machine without worrying about the firewall. - John Airey Internet systems support officer, ITCSD, Royal National Institute for the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] Agnostic (Greek) = Ignoramus (Latin) >-Original Message- >From: Stanley Hopcroft [mailto:[EMAIL PROTECTED]] >Sent: 14 January 2002 09:36 >To: [EMAIL PROTECTED] >Subject: Re: Why DNS/IP in certificate? > > >Deear Ladies and Gentlemen, > >I am writing to thank you for your comments about this matter and ask > >On Thu, Jan 10, 2002 at 09:34:50AM -0500, Neff Robert A wrote: >> >> The client needs to verify who it is connected to. >> Anyone in the world can present a certificate to >> establish an ssl connection. In a nutshell, the >> checks that need to be made on the client end are: >> a. Do you trust the signer of the certificate received >> b. Is the CN contained within the cert what you expect >> > >..snip.. > >> Your next task is to ensure that the >> trusted cert truly came from the site you expected and >> not www.someothersite.com. The browser does this step by >> comparing the CN contained in the cert to the URL address >> typed into your browser. Your own app must do so as well... >> > >is it possible to have an OpenSSL server located behind a >Network Adress >Transalation device (a NET device is sometimes part of firewalls, eg >the Cisco PIX) and still have the client handshake complete without >error ? > >Here is the scenario. > >Server has valid certificate signed by root CA for Distinguished Name >'S'. > >DNS responds to an A record request from the client for S, with the >public interface of the NAT device (PTR query for that address also >returns S), but the OpenSSL server with that cert has a completely >different address (because its been translated) > >One might do this because of outsourcing or merger activities that >result in a new or different firewall. > >Presumably the network between the NAT box and the OpenSSL server is >secure enough to be tolerablee. > >So :- > >1 Will the scenario above work ? >2 If not, how can it be made to work ? > >Thank you, > >Yours sincerely. > >-- >--- >- >Stanley Hopcroft Network >Specialist >--- >- > >'...No man is an island, entire of itself; every man is a piece of the >continent, a part of the main. If a clod be washed away by the sea, >Europe is the less, as well as if a promontory were, as well as if a >manor of thy friend's or of thine own were. Any man's death diminishes >me, because I am involved in mankind; and therefore never send to know >for whom the bell tolls; it tolls for thee...' > >from Meditation 17, J Donne. >__ >OpenSSL Project http://www.openssl.org >User Support Mailing List[EMAIL PROTECTED] >Automated List Manager [EMAIL PROTECTED] > - NOTICE: The information contained in this email and any attachments is confidential and may be legally privileged. If you are not the intended recipient you are hereby notified that you must not use, disclose, distribute, copy, print or rely on this email's content. If you are not the intended recipient, pleas
RE: Why DNS/IP in certificate?
I haven't yet seen discussion of one interesting aspect of this issue from the viewpoint of the TLS specification. The TLS specification says (in RFC 2818) that the client must first compare all subjectAltName extensions with type dNSName to the intended server's identity. That can include wildcarded values. Then the client must check the most specific commonName field. The RFC goes on to say that while use of commonName to hold a server's identity is existing practice, it is deprecated. OpenSSL does it right, BTW. Vic Abell <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Why DNS/IP in certificate?
- Original Message - From: "Stanley Hopcroft" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 14, 2002 10:36 AM Subject: Re: Why DNS/IP in certificate? > Deear Ladies and Gentlemen, > > I am writing to thank you for your comments about this matter and ask > > On Thu, Jan 10, 2002 at 09:34:50AM -0500, Neff Robert A wrote: > > > > The client needs to verify who it is connected to. > > Anyone in the world can present a certificate to > > establish an ssl connection. In a nutshell, the > > checks that need to be made on the client end are: > > a. Do you trust the signer of the certificate received > > b. Is the CN contained within the cert what you expect > > > > ..snip.. > > > Your next task is to ensure that the > > trusted cert truly came from the site you expected and > > not www.someothersite.com. The browser does this step by > > comparing the CN contained in the cert to the URL address > > typed into your browser. Your own app must do so as well... > > > > is it possible to have an OpenSSL server located behind a Network Adress > Transalation device (a NET device is sometimes part of firewalls, eg > the Cisco PIX) and still have the client handshake complete without > error ? > > Here is the scenario. > > Server has valid certificate signed by root CA for Distinguished Name > 'S'. > > DNS responds to an A record request from the client for S, with the > public interface of the NAT device (PTR query for that address also > returns S), but the OpenSSL server with that cert has a completely > different address (because its been translated) > > One might do this because of outsourcing or merger activities that > result in a new or different firewall. > > Presumably the network between the NAT box and the OpenSSL server is > secure enough to be tolerablee. > > So :- > > 1 Will the scenario above work ? > 2 If not, how can it be made to work ? > > Thank you, > > Yours sincerely. > > -- > > Stanley Hopcroft Network Specialist > > > '...No man is an island, entire of itself; every man is a piece of the > continent, a part of the main. If a clod be washed away by the sea, > Europe is the less, as well as if a promontory were, as well as if a > manor of thy friend's or of thine own were. Any man's death diminishes > me, because I am involved in mankind; and therefore never send to know > for whom the bell tolls; it tolls for thee...' > > from Meditation 17, J Donne. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Why DNS/IP in certificate?
> While I agree with the other points: > OpenSSL itself does not contain any code to performs these checks: > therefore it does not do it wrong but it also does not do it right; > it doesn't do anything :-) > > Best regards, > Lutz Lutz is right. I've been looking at so much Open* software lately that I swapped OpenSSL with OpenLDAP. It is OpenLDAP that checks the server identity in proper conformance to the TLS specification. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
