 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / September 2005what certificate to buy from Verisign ?
Hi, my company plans to use WSE2.0 sp3 to secure the webservice communication between us and the client. now that we are looking at Verisign on what exactly to buy but the sales person at Verisign were not very helpful. and MSDN didn't provide any information on what exact certificate to buy from Verisign either, all it says is get certificate from a trusted CA, for example: Verisign. could someone point out which product to buy from verisign? some information on what I found so far: 1. after searched around, seems a lot of people are complaining Verisign sales have no idea what to buy to encrypt and sign web services. 2. some people seem got regular SSL certificates working to encrypt and sign web service request, but will there be performance issues? is it recommened by Microsoft that an existing SSL certificate can be used for encrypt and sign webservice requests? 3. some people in various newsgroups are talking about using the Digital ID product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica tion/email-digital-id/index.html), this is a product from Verisign to secure emails. is this correct to use Digital ID? this thing is much cheaper than regular SSL certificates, only $19.99/Year Please help, thanks a lot. Hi Jason, AS for the Certificate type you mentioned, for your scenario, since the certificate is mainly used to identitfy your server application and build a secure communication channel between client/server, I think a normal web server certificate is enough. Of course, there must has some guys from Verisign who will help you find the proper certificate for yoru application. Thanks, Steven Cheng Microsoft Online Support  SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: <jason.chen@newsgroups.nospam> Subject: what certificate to buy from Verisign ? Date: Wed, 14 Sep 2005 12:52:04 -0400 Lines: 29 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.326 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Message-ID: <Oo3#jyUuFHA.3756@tk2msftngp13.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4873 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements Hi, my company plans to use WSE2.0 sp3 to secure the webservice communication between us and the client. now that we are looking at Verisign on what exactly to buy but the sales person at Verisign were not very helpful. and MSDN didn't provide any information on what exact certificate to buy from Verisign either, all it says is get certificate from a trusted CA, for example: Verisign. could someone point out which product to buy from verisign? some information on what I found so far: 1. after searched around, seems a lot of people are complaining Verisign sales have no idea what to buy to encrypt and sign web services. 2. some people seem got regular SSL certificates working to encrypt and sign web service request, but will there be performance issues? is it recommened by Microsoft that an existing SSL certificate can be used for encrypt and sign webservice requests? 3. some people in various newsgroups are talking about using the Digital ID product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica tion/email-digital-id/index.html), this is a product from Verisign to secure emails. is this correct to use Digital ID? this thing is much cheaper than regular SSL certificates, only $19.99/Year Please help, thanks a lot. thanks Steven, I guess the server side can just purchase the normal webserver certificate, what about the client side who consumes the webservice? should they also get a normal webserver certificate or something particular? many thanks, -jason > Hi Jason, > [quoted text clipped - 52 lines] > 3. some people in various newsgroups are talking about using the Digital ID > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > tion/email-digital-id/index.html), this is a product from Verisign to secure > emails. is this correct to use Digital ID? this thing is much cheaper than > regular SSL certificates, only $19.99/Year > > Please help, thanks a lot. Thanks for your response Jason, As for the webservice client, it all depends on your application's security authetication design. If you server doesn't use some authentication schema which require client certificates(x509 authentication based token authentication....) or the server dosn't require the client to use a certain certificate to identitfy clientside, then client app do not need to have a own certificate. This is just like when we use SSL without requiring clientside certificate. Also, since you're using WSE, if you have used x509 certificate token to sign message at both client/serverside, then, the clientside also must have its own certificate. Thanks, Steven Cheng Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: <jason.chen@newsgroups.nospam> References: <Oo3#jyUuFHA.3756@tk2msftngp13.phx.gbl> <NRnDAzcuFHA.768@TK2MSFTNGXA01.phx.gbl> Subject: Re: what certificate to buy from Verisign ? Date: Thu, 15 Sep 2005 10:19:53 -0400 Lines: 83 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.326 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Message-ID: <uK1wLCguFHA.596@TK2MSFTNGP12.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4884 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements thanks Steven, I guess the server side can just purchase the normal webserver certificate, what about the client side who consumes the webservice? should they also get a normal webserver certificate or something particular? many thanks, -jason > Hi Jason, > [quoted text clipped - 33 lines] > Hi, my company plans to use WSE2.0 sp3 to secure the webservice > communication between us and the client. now that we are looking at Verisign > on what exactly to buy but the sales person at Verisign were not very > helpful. and MSDN didn't provide any information on what exact certificate [quoted text clipped - 14 lines] > > 3. some people in various newsgroups are talking about using the Digital ID > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > tion/email-digital-id/index.html), this is a product from Verisign to secure > emails. is this correct to use Digital ID? this thing is much cheaper than > regular SSL certificates, only $19.99/Year > > Please help, thanks a lot. hi Steven, I'd like X509 certificate to be used by both client and server, you mentioned the server side can use a regular SSL certificate, can client also use a regular ssl certificate on client side? thanks, -Jason > Thanks for your response Jason, > [quoted text clipped - 103 lines] > ID > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > tion/email-digital-id/index.html), this is a product from Verisign to > secure > > emails. is this correct to use Digital ID? this thing is much cheaper than > > regular SSL certificates, only $19.99/Year > > > > Please help, thanks a lot. Hi Jason, Server certificate is used by server service, and is not necessary for client app. For client side, there has Client Authentication Certificate respectively. In fact, you find a certain windows 2000 or 2003 server machine which can install the Microsoft Certificate Service, so that you can create/send certificate request to it , from which you can see those most popular types of certificates. In addition, professional Authority like Verisign will have much more types of certificates available, so I still think it better you consult them on your scenario. Thanks, Steven Cheng Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: <jason.chen@newsgroups.nospam> References: <Oo3#jyUuFHA.3756@tk2msftngp13.phx.gbl> <NRnDAzcuFHA.768@TK2MSFTNGXA01.phx.gbl> <uK1wLCguFHA.596@TK2MSFTNGP12.phx.gbl> <dlKkV7luFHA.768@TK2MSFTNGXA01.phx.gbl> Subject: Re: what certificate to buy from Verisign ? Date: Thu, 15 Sep 2005 23:52:07 -0400 Lines: 146 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.326 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Message-ID: <uKVnDInuFHA.3500@TK2MSFTNGP09.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements NNTP-Posting-Host: a7cebc02.cst.lightpath.net 167.206.188.2 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4897 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements hi Steven, I'd like X509 certificate to be used by both client and server, you mentioned the server side can use a regular SSL certificate, can client also use a regular ssl certificate on client side? thanks, -Jason > Thanks for your response Jason, > > As for the webservice client, it all depends on your application's security > authetication design. If you server doesn't use some authentication schema > which require client certificates(x509 authentication based token > authentication....) or the server dosn't require the client to use a > certain certificate to identitfy clientside, then client app do not need to > have a own certificate. This is just like when we use SSL without > requiring clientside certificate. Also, since you're using WSE, if you > have used x509 certificate token to sign message at both client/serverside, > then, the clientside also must have its own certificate. > [quoted text clipped - 29 lines] > webserver certificate, what about the client side who consumes the > webservice? should they also get a normal webserver certificate or something > particular? > [quoted text clipped - 7 lines] > > AS for the Certificate type you mentioned, for your scenario, since the > > certificate is mainly used to identitfy your server application and build > a > > secure communication channel between client/server, I think a normal web [quoted text clipped - 33 lines] > > on what exactly to buy but the sales person at Verisign were not very > > helpful. and MSDN didn't provide any information on what exact certificate > > to buy from Verisign either, all it says is get certificate from a trusted > > CA, for example: Verisign. > > [quoted text clipped - 13 lines] > ID > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > tion/email-digital-id/index.html), this is a product from Verisign to > secure > > emails. is this correct to use Digital ID? this thing is much cheaper than > > regular SSL certificates, only $19.99/Year > > > > Please help, thanks a lot. thanks steven for following up, I guess I have to schedule a call with verisign to work this out then. -Jason > Hi Jason, > [quoted text clipped - 161 lines] > > ID > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > tion/email-digital-id/index.html), this is a product from Verisign to > > secure [quoted text clipped - 3 lines] > > > > > > Please help, thanks a lot. You're welcome Jason, If there're any further things we can help later, please feel free to post here. Good luck! Steven Cheng Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: <jason.chen@newsgroups.nospam> References: <Oo3#jyUuFHA.3756@tk2msftngp13.phx.gbl> <NRnDAzcuFHA.768@TK2MSFTNGXA01.phx.gbl> <uK1wLCguFHA.596@TK2MSFTNGP12.phx.gbl> <dlKkV7luFHA.768@TK2MSFTNGXA01.phx.gbl> <uKVnDInuFHA.3500@TK2MSFTNGP09.phx.gbl> <gRqUmbouFHA.1080@TK2MSFTNGXA01.phx.gbl> Subject: Re: what certificate to buy from Verisign ? Date: Sun, 18 Sep 2005 16:13:51 -0400 Lines: 212 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.326 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Message-ID: <Oxmu91IvFHA.3452@TK2MSFTNGP14.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4913 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements thanks steven for following up, I guess I have to schedule a call with verisign to work this out then. -Jason > Hi Jason, > [quoted text clipped - 40 lines] > I'd like X509 certificate to be used by both client and server, you > mentioned the server side can use a regular SSL certificate, can client also > use a regular ssl certificate on client side? > [quoted text clipped - 8 lines] > security > > authetication design. If you server doesn't use some authentication schema > > which require client certificates(x509 authentication based token > > authentication....) or the server dosn't require the client to use a > > certain certificate to identitfy clientside, then client app do not need > to > > have a own certificate. This is just like when we use SSL without > > requiring clientside certificate. Also, since you're using WSE, if you > > have used x509 certificate token to sign message at both > client/serverside, [quoted text clipped - 40 lines] > > > > > > AS for the Certificate type you mentioned, for your scenario, since the > > > certificate is mainly used to identitfy your server application and > build > > a > > > secure communication channel between client/server, I think a normal web > > > server certificate is enough. Of course, there must has some guys from > > > Verisign who will help you find the proper certificate for yoru > > > application. [quoted text clipped - 40 lines] > > > > > > 1. after searched around, seems a lot of people are complaining Verisign > > > sales have no idea what to buy to encrypt and sign web services. > > > > > > 2. some people seem got regular SSL certificates working to encrypt and > > > sign web service request, but will there be performance issues? is it > > > recommened by Microsoft that an existing SSL certificate can be used for > > > encrypt and sign webservice requests? > > > > > > 3. some people in various newsgroups are talking about using the Digital > > ID > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > tion/email-digital-id/index.html), this is a product from Verisign to > > secure [quoted text clipped - 3 lines] > > > > > > Please help, thanks a lot. HI Steven, this is an update on this thread, I just had a call with a Verisign senior engineer, and he had very strong opinions on using asymetric encryptions. first thing he said when I tried to explain to him WSE2 uses asymetric encryption is 'asymetric encryption is 1000 times slower than symetric encryption', then he recommended to use HTTPS protocol to protect the data on the transport level instead of using HTTP and protect the data on the application level. he also said by protecting data on application level, it'll be much slower and will be easier for brute force attack. what I'd like to find out from you is, do you have any performance matrix on how much performance overhead will be added by using x.509 certificates to encrypt the sign the data comparing to not encrypting and sign the data? also, do you have any comment on using HTTPS vs. using HTTP + WSE2 encryption and signing? thanks, -Jason > You're welcome Jason, > [quoted text clipped - 212 lines] > > > ID > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > > tion/email-digital-id/index.html), this is a product from Verisign to > > > secure [quoted text clipped - 3 lines] > > > > > > > > Please help, thanks a lot. > first thing he said when I tried to explain to him WSE2 uses asymetric > encryption is 'asymetric encryption is 1000 times slower than symetric [quoted text clipped - 8 lines] > also, do you have any comment on using HTTPS vs. using HTTP + WSE2 > encryption and signing? I think what your looking for is SecurityContextToken (SCT). You get SCT using a negotiated key exchange which requires a server cert. Once you have the SCT, you have a symmetric key (in the SCT) that will be used to encrypt the body and do signature. Pretty similar to SSL, but at the msg element level (i.e. you pick body, tokens, etc) instead of everything that goes over the wire. SignatureWilliam Stacey [MVP] Hi William, I raised a similar question in my reply to Steven, so here it goes, once you used SCT to exchange the symmetric key, can you use that key for other requests? or do you have to use SCT to exchange a symmertric key for every request? thanks, -Jason > > first thing he said when I tried to explain to him WSE2 uses asymetric > > encryption is 'asymetric encryption is 1000 times slower than symetric [quoted text clipped - 15 lines] > level (i.e. you pick body, tokens, etc) instead of everything that goes over > the wire. Hi Jason, Thanks for your followup. The verisign guy's suggestion is reasonable from security perspective since Asymmetric encryption is really more secure, but also more performance cost. Generally, we'll use asymmetric encrytion to transfer sessionkey and then use that sessionkey to do symmetric encryption for all the sequential commuincation. That's also what SLL/TLS does. For HTTPS/SSL, of course I'd recommend you consider it if SSL/TLS is really possible for your scenario. The SSL/TLS just provide a secuire point to point channel which ensure confidential, integrity .... And though WSE also priovde these features, the SSL/TLS's implementation is surely more robust and sophisticated. And the WSE's strong point is that it provide more flexible and wide applicaiton scenario, which is not limited to webserver scenario, (generally SSL/TLS require our server service be hosted in a sophisticated webserver like IIS/ Apache or other applicaiton server). While WSE application can be hosted in any .NET application. Thanks, Steven Cheng Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: <jason.chen@newsgroups.nospam> References: <Oo3#jyUuFHA.3756@tk2msftngp13.phx.gbl> <NRnDAzcuFHA.768@TK2MSFTNGXA01.phx.gbl> <uK1wLCguFHA.596@TK2MSFTNGP12.phx.gbl> <dlKkV7luFHA.768@TK2MSFTNGXA01.phx.gbl> <uKVnDInuFHA.3500@TK2MSFTNGP09.phx.gbl> <gRqUmbouFHA.1080@TK2MSFTNGXA01.phx.gbl> <Oxmu91IvFHA.3452@TK2MSFTNGP14.phx.gbl> <gGB5JtLvFHA.768@TK2MSFTNGXA01.phx.gbl> Subject: FOLLOW UP - Re: what certificate to buy from Verisign ? Date: Tue, 20 Sep 2005 12:43:28 -0400 Lines: 284 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.326 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Message-ID: <eqSVtJgvFHA.2076@TK2MSFTNGP14.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4929 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements HI Steven, this is an update on this thread, I just had a call with a Verisign senior engineer, and he had very strong opinions on using asymetric encryptions. first thing he said when I tried to explain to him WSE2 uses asymetric encryption is 'asymetric encryption is 1000 times slower than symetric encryption', then he recommended to use HTTPS protocol to protect the data on the transport level instead of using HTTP and protect the data on the application level. he also said by protecting data on application level, it'll be much slower and will be easier for brute force attack. what I'd like to find out from you is, do you have any performance matrix on how much performance overhead will be added by using x.509 certificates to encrypt the sign the data comparing to not encrypting and sign the data? also, do you have any comment on using HTTPS vs. using HTTP + WSE2 encryption and signing? thanks, -Jason > You're welcome Jason, > [quoted text clipped - 42 lines] > > Server certificate is used by server service, and is not necessary for > > client app. For client side, there has Client Authentication Certificate > > respectively. In fact, you find a certain windows 2000 or 2003 server > > machine which can install the Microsoft Certificate Service, so that you > > can create/send certificate request to it , from which you can see those > > most popular types of certificates. In addition, professional Authority > > like Verisign will have much more types of certificates available, so I > > still think it better you consult them on your scenario. [quoted text clipped - 47 lines] > > > authentication....) or the server dosn't require the client to use a > > > certain certificate to identitfy clientside, then client app do not need > > to > > > have a own certificate. This is just like when we use SSL without [quoted text clipped - 79 lines] > > > > NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 > > > > Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl > > > > Xref: TK2MSFTNGXA01.phx.gbl > > > > microsoft.public.dotnet.framework.webservices.enhancements:4873 [quoted text clipped - 5 lines] > > > Verisign > > > > on what exactly to buy but the sales person at Verisign were not very > > > > helpful. and MSDN didn't provide any information on what exact > > certificate [quoted text clipped - 13 lines] > and > > > > sign web service request, but will there be performance issues? is it > > > > recommened by Microsoft that an existing SSL certificate can be used > for [quoted text clipped - 4 lines] > > > ID > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > > tion/email-digital-id/index.html), this is a product from Verisign to > > > secure > > > > emails. is this correct to use Digital ID? this thing is much cheaper > > than > > > > regular SSL certificates, only $19.99/Year > > > > > > > > Please help, thanks a lot. Hi Steven, thanks for getting back to me. SSL is possible in my scenario, but I have some doubts about using SSL in a server to server scenario, let me explain: in a typical scenario of Browser talking to server through SSL, a SSL handshake is done, and a session key is established, session key is transferred back to browser from server. and browser can use the generated session key to send request to the server as long as the browser remain open. if browser closes down, session will be lost, if new browser instance opens, new SSL handshake have to be done, new session key will be generated and transferred back to browser. in a sccenario of server talking to server through SSL, SSL handshake will be done when server tries to send request to the other server through https. session key will be transferred back, and as long as the connection not closed down, same session key will be used. the catch here is in most server to server scenario, I think connections have to be closed once the request is done. or in this scenario, should we put the opened https connection into a connection pool? I think I'm lost in this. also, will the session key ever expire? thanks, -jason > Hi Jason, > [quoted text clipped - 295 lines] > > > > ID > > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > > > tion/email-digital-id/index.html), this is a product from Verisign > to [quoted text clipped - 5 lines] > > > > > > > > > > Please help, thanks a lot. Hi Jason, Of course the sessionkey will be expired and regenerated after connection closed and new connection established. Also, during a live connection's lifecycle, the SessionKey will also expire and be regenerated according to the timespan is has across so as to ensure the channel's secure. In addition, for SSL between server to server, I think it's the same with client to server, in fact when a server use HTTPS to call webservice at another server protected by SSL/TLS, the server which send the request is just the "CLIENT", so server/client is a logic concept. Thanks, Steven Cheng Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: <jason.chen@newsgroups.nospam> References: <Oo3#jyUuFHA.3756@tk2msftngp13.phx.gbl> <NRnDAzcuFHA.768@TK2MSFTNGXA01.phx.gbl> <uK1wLCguFHA.596@TK2MSFTNGP12.phx.gbl> <dlKkV7luFHA.768@TK2MSFTNGXA01.phx.gbl> <uKVnDInuFHA.3500@TK2MSFTNGP09.phx.gbl> <gRqUmbouFHA.1080@TK2MSFTNGXA01.phx.gbl> <Oxmu91IvFHA.3452@TK2MSFTNGP14.phx.gbl> <gGB5JtLvFHA.768@TK2MSFTNGXA01.phx.gbl> <eqSVtJgvFHA.2076@TK2MSFTNGP14.phx.gbl> <M10VK0ovFHA.580@TK2MSFTNGXA01.phx.gbl> Subject: Re: FOLLOW UP - Re: what certificate to buy from Verisign ? Date: Wed, 21 Sep 2005 12:58:55 -0400 Lines: 388 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.326 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Message-ID: <ei#DE3svFHA.908@tk2msftngp13.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4946 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements Hi Steven, thanks for getting back to me. SSL is possible in my scenario, but I have some doubts about using SSL in a server to server scenario, let me explain: in a typical scenario of Browser talking to server through SSL, a SSL handshake is done, and a session key is established, session key is transferred back to browser from server. and browser can use the generated session key to send request to the server as long as the browser remain open. if browser closes down, session will be lost, if new browser instance opens, new SSL handshake have to be done, new session key will be generated and transferred back to browser. in a sccenario of server talking to server through SSL, SSL handshake will be done when server tries to send request to the other server through https. session key will be transferred back, and as long as the connection not closed down, same session key will be used. the catch here is in most server to server scenario, I think connections have to be closed once the request is done. or in this scenario, should we put the opened https connection into a connection pool? I think I'm lost in this. also, will the session key ever expire? thanks, -jason > Hi Jason, > > Thanks for your followup. > The verisign guy's suggestion is reasonable from security perspective since > Asymmetric encryption is really more secure, but also more performance > cost. Generally, we'll use asymmetric encrytion to transfer sessionkey > and then use that sessionkey to do symmetric encryption for all the > sequential commuincation. That's also what SLL/TLS does. > > For HTTPS/SSL, of course I'd recommend you consider it if SSL/TLS is really > possible for your scenario. The SSL/TLS just provide a secuire point to > point channel which ensure confidential, integrity .... And though WSE > also priovde these features, the SSL/TLS's implementation is surely more > robust and sophisticated. And the WSE's strong point is that it provide > more flexible and wide applicaiton scenario, which is not limited to > webserver scenario, (generally SSL/TLS require our server service be hosted > in a sophisticated webserver like IIS/ Apache or other applicaiton > server). While WSE application can be hosted in any .NET application. [quoted text clipped - 57 lines] > > > > If there're any further things we can help later, please feel free to post > > here. > > Good luck! [quoted text clipped - 40 lines] > > > respectively. In fact, you find a certain windows 2000 or 2003 server > > > machine which can install the Microsoft Certificate Service, so that you > > > can create/send certificate request to it , from which you can see those > > > most popular types of certificates. In addition, professional > Authority [quoted text clipped - 33 lines] > > > hi Steven, > > > I'd like X509 certificate to be used by both client and server, you > > > mentioned the server side can use a regular SSL certificate, can client > > also > > > use a regular ssl certificate on client side? [quoted text clipped - 17 lines] > > > > have a own certificate. This is just like when we use SSL without > > > > requiring clientside certificate. Also, since you're using WSE, if > > you > > > > have used x509 certificate token to sign message at both [quoted text clipped - 25 lines] > > > > NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 > > > > Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl > > > > Xref: TK2MSFTNGXA01.phx.gbl > > > > microsoft.public.dotnet.framework.webservices.enhancements:4884 [quoted text clipped - 13 lines] > > > > > > > > > > AS for the Certificate type you mentioned, for your scenario, since > > the > > > > > certificate is mainly used to identitfy your server application and > > > build > > > > a > > > > > secure communication channel between client/server, I think a normal > > web > > > > > server certificate is enough. Of course, there must has some guys [quoted text clipped - 34 lines] > > > > > Hi, my company plans to use WSE2.0 sp3 to secure the webservice > > > > > communication between us and the client. now that we are looking at > > > > Verisign > > > > > on what exactly to buy but the sales person at Verisign were not [quoted text clipped - 14 lines] > > > > > > > > > > 2. some people seem got regular SSL certificates working to encrypt > > and > > > > > sign web service request, but will there be performance issues? is > it > > > > > recommened by Microsoft that an existing SSL certificate can be used > > for > > > > > encrypt and sign webservice requests? [quoted text clipped - 3 lines] > > > > ID > > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > > > tion/email-digital-id/index.html), this is a product from Verisign > to [quoted text clipped - 5 lines] > > > > > > > > > > Please help, thanks a lot. Hi Steven, usually in a server to server scenario, once response is received, the *client* who sends the request will close down the connection. I think that's the diffference comparing to browser to server scenario? I know the SSL handshake is an expensive operation, if I choose to use SSL to access the webservice, that'll mean everytime I send a request to the webservice, a new connection is established, and SSL handshake will be done, then we lose the benefit of re-using the same session key, is it correct? thanks, -Jason > Hi Jason, > [quoted text clipped - 388 lines] > > > > > ID > > > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > > > > tion/email-digital-id/index.html), this is a product from Verisign > > to [quoted text clipped - 5 lines] > > > > > > > > > > > > Please help, thanks a lot. If you use SCT (recommended) it goes something like this: 1) Session key exchange using Certs to exchange and verify identities. I think you can demand client also has cert. 2) Both sides now have a SecurityContextToken which includes the SKey and the SCT ID and expire datetime. 3) Server caches the SCT using SCTID is unique id. 4) Client signs/encrypts future messages with the SCT. 5) Server receives message and looks up SCT via ID and verifies the message signature using the SKey it knows for that SCTID. If bad, exception. 6) Client can continue to use SCT without handshake until SCT expires. Then needs to do SCT exchange again. SignatureWilliam Stacey [MVP] > Hi Steven, > usually in a server to server scenario, once response is received, the [quoted text clipped - 466 lines] >> > > > > > >> > > > > > Please help, thanks a lot. Hi William, thanks for your explanation on SCT, one question, what will happen if server is running in a cluster environment? one of the servers will cache the SCT, but next time client sends a request with the SCT, the server handles the request maybe a server that does not have the SCT cached. thanks, -Jason > If you use SCT (recommended) it goes something like this: > 1) Session key exchange using Certs to exchange and verify identities. I [quoted text clipped - 421 lines] > >> > TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl > >> > > > > > Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4873 > >> > > > > > X-Tomcat-NG: > >> > > microsoft.public.dotnet.framework.webservices.enhancements [quoted text clipped - 40 lines] > >> > > > > ID > >> > > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > >> > > > > > tion/email-digital-id/index.html), this is a product from > > Verisign [quoted text clipped - 6 lines] > >> > > > > > > >> > > > > > Please help, thanks a lot. I have seen this done before. What they did was write the SCT data (i.e. ID, key, Start Date, Expire Date) to shared DB (i.e. SQL, xml file, etc). Then, IIRC, there is an overload to find an SCT if not in the local cache so you then look it up and cache it locally. SignatureWilliam Stacey [MVP] > Hi William, > thanks for your explanation on SCT, one question, what will happen if [quoted text clipped - 547 lines] >> >> > > > > > >> >> > > > > > Please help, thanks a lot. Hi Jason, Yes, when calling webservice which is SSL protected from cilent proxy, the connection may not be utilized as efficient as the browser since the underlying HttpWebrequest component's implementation is not guaranteed on such connection caching. However, due to the sophisticated secure of the SSL/TLS, many people still choose this approach in their webservice communication. Also, as WSE since the WSE components manually implement what the SSL/TLS do (though not as perfect as it), we have more flexibility over the connections controling when using WSE. Anyway, if you do have critical concerns on the performance, it's better to perform some simple tests through the two means which may give us a clear view. Thanks, Steven Cheng Microsoft Online Support SignatureGet Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: <jason.chen@newsgroups.nospam> References: <Oo3#jyUuFHA.3756@tk2msftngp13.phx.gbl> <NRnDAzcuFHA.768@TK2MSFTNGXA01.phx.gbl> <uK1wLCguFHA.596@TK2MSFTNGP12.phx.gbl> <dlKkV7luFHA.768@TK2MSFTNGXA01.phx.gbl> <uKVnDInuFHA.3500@TK2MSFTNGP09.phx.gbl> <gRqUmbouFHA.1080@TK2MSFTNGXA01.phx.gbl> <Oxmu91IvFHA.3452@TK2MSFTNGP14.phx.gbl> <gGB5JtLvFHA.768@TK2MSFTNGXA01.phx.gbl> <eqSVtJgvFHA.2076@TK2MSFTNGP14.phx.gbl> <M10VK0ovFHA.580@TK2MSFTNGXA01.phx.gbl> <ei#DE3svFHA.908@tk2msftngp13.phx.gbl> <2sOVJa0vFHA.1616@TK2MSFTNGXA01.phx.gbl> Subject: Re: FOLLOW UP - Re: what certificate to buy from Verisign ? Date: Thu, 22 Sep 2005 14:46:35 -0400 Lines: 481 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.3790.326 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Message-ID: <O13W2X6vFHA.3000@TK2MSFTNGP12.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4959 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements Hi Steven, usually in a server to server scenario, once response is received, the *client* who sends the request will close down the connection. I think that's the diffference comparing to browser to server scenario? I know the SSL handshake is an expensive operation, if I choose to use SSL to access the webservice, that'll mean everytime I send a request to the webservice, a new connection is established, and SSL handshake will be done, then we lose the benefit of re-using the same session key, is it correct? thanks, -Jason > Hi Jason, > [quoted text clipped - 53 lines] > session key to send request to the server as long as the browser remain > open. if browser closes down, session will be lost, if new browser instance > opens, new SSL handshake have to be done, new session key will be generated > and transferred back to browser. > > in a sccenario of server talking to server through SSL, SSL handshake will > be done when server tries to send request to the other server through https. > session key will be transferred back, and as long as the connection not > closed down, same session key will be used. the catch here is in most server > to server scenario, I think connections have to be closed once the request > is done. or in this scenario, should we put the opened https connection into > a connection pool? I think I'm lost in this. also, will the session key ever > expire? > [quoted text clipped - 17 lines] > > possible for your scenario. The SSL/TLS just provide a secuire point to > > point channel which ensure confidential, integrity .... And though WSE > > also priovde these features, the SSL/TLS's implementation is surely more > > robust and sophisticated. And the WSE's strong point is that it provide [quoted text clipped - 42 lines] > > encryptions. > > first thing he said when I tried to explain to him WSE2 uses asymetric > > encryption is 'asymetric encryption is 1000 times slower than symetric > > encryption', then he recommended to use HTTPS protocol to protect the data > > on the transport level instead of using HTTP and protect the data on the > > application level. he also said by protecting data on application level, > > it'll be much slower and will be easier for brute force attack. > > what I'd like to find out from you is, do you have any performance > > matrix on how much performance overhead will be added by using x.509 > > certificates to encrypt the sign the data comparing to not encrypting and > > sign the data? > > also, do you have any comment on using HTTPS vs. using HTTP + WSE2 [quoted text clipped - 49 lines] > > > > > > > > Server certificate is used by server service, and is not necessary for > > > > client app. For client side, there has Client Authentication > > Certificate > > > > respectively. In fact, you find a certain windows 2000 or 2003 server > > > > machine which can install the Microsoft Certificate Service, so that > you [quoted text clipped - 3 lines] > > Authority > > > > like Verisign will have much more types of certificates available, so > I > > > > still think it better you consult them on your scenario. [quoted text clipped - 25 lines] > > > > NNTP-Posting-Host: a7cebc02.cst.lightpath.net 167.206.188.2 > > > > Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.phx.gbl > > > > Xref: TK2MSFTNGXA01.phx.gbl > > > > microsoft.public.dotnet.framework.webservices.enhancements:4897 [quoted text clipped - 17 lines] > > > > security > > > > > authetication design. If you server doesn't use some authentication > > > schema > > > > > which require client certificates(x509 authentication based token > > > > > authentication....) or the server dosn't require the client to use > a > > > > > certain certificate to identitfy clientside, then client app do not > > need > > > > to > > > > > have a own certificate. This is just like when we use SSL without > > > > > requiring clientside certificate. Also, since you're using WSE, > if [quoted text clipped - 36 lines] > > > > > > > > > > thanks Steven, I guess the server side can just purchase the normal > > > > > webserver certificate, what about the client side who consumes the > > > > > webservice? should they also get a normal webserver certificate or [quoted text clipped - 19 lines] > > > web > > > > > > server certificate is enough. Of course, there must has some guys > > > from > > > > > > Verisign who will help you find the proper certificate for yoru [quoted text clipped - 54 lines] > > > and > > > > > > sign web service request, but will there be performance issues? is > > it > > > > > > recommened by Microsoft that an existing SSL certificate can be [quoted text clipped - 6 lines] > > > > > ID > > > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > > > > tion/email-digital-id/index.html), this is a product from Verisign > > to > > > > > secure [quoted text clipped - 4 lines] > > > > > > > > > > > > Please help, thanks a lot. thanks steve, I'll do some testing over these 2 scenarios and see what happens. thanks, -Jason > Hi Jason, > [quoted text clipped - 440 lines] > > > TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl > > > > > > > Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4873 > > > > > > > X-Tomcat-NG: > > > > microsoft.public.dotnet.framework.webservices.enhancements [quoted text clipped - 35 lines] > > > > > > ID > > > > > > > product from Verisign to encrypt and sign webservice requests, (http://www.verisign.com/products-services/security-services/pki/pki-applica > > > > > > > tion/email-digital-id/index.html), this is a product from > Verisign [quoted text clipped - 6 lines] > > > > > > > > > > > > > > Please help, thanks a lot. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.