 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / October 2005how can we restrict what certificate WSE will use?
assume I'm hosting a webservice, I have 2 trusted clients consume my webservice, each client will send in properly encrypted and signed request, WSE will take care of decryption and verification of the signature, everything works great. now there is a hacker, tries to consume my webservice, he encrypted his request using my public key, and signed his request using his own private key, when I received the request WSE will automatically decrypt it and verify the signature successfully before reaching my code where I verify it's a trusted client. as you can see, the decryption and signature verify happens automatically before I can check if it's a trusted client. my question is, is there a way I can short circuit this process so that I can terminate the request before decryption/ signature verification happens? thanks, -Jason Hi Jason, As for the question on the X509 certificate verification in .net webservice using WSE, here are some of my understanding and suggestions: When a hacker use your public key (server certificate) to encrypte the message, it's ok. However, since his private key is not valid so, the signature of his message won't be able to be verified at the serverside. Also, we must have authentication protection at serverside through securityTokens(UsernameToken or X509CertificateToken ...). So are you using X509CertificateToken for authentication? If so you can consider defining a custom TokenManager class for X509Certificate Authentication. We can create such a class which dervied from the Microsoft.Web.Services2.Security.Tokens.X509SecurityTokenManager class This class has a "AuthenticateToken" method protected virtual void AuthenticateToken( X509SecurityToken token ); which is used to verify the clientside x509certificate token, we can override this method in our custom manager class to do our own verfiy processing. Also, you can search the class in the WSE documentation and there're also reference on our to register custom Token Manager class within service's config file. 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: how can we restrict what certificate WSE will use? Date: Sun, 18 Sep 2005 17:07:24 -0400 Lines: 18 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: <O9Bv4TJvFHA.3236@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:4914 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements assume I'm hosting a webservice, I have 2 trusted clients consume my webservice, each client will send in properly encrypted and signed request, WSE will take care of decryption and verification of the signature, everything works great. now there is a hacker, tries to consume my webservice, he encrypted his request using my public key, and signed his request using his own private key, when I received the request WSE will automatically decrypt it and verify the signature successfully before reaching my code where I verify it's a trusted client. as you can see, the decryption and signature verify happens automatically before I can check if it's a trusted client. my question is, is there a way I can short circuit this process so that I can terminate the request before decryption/ signature verification happens? thanks, -Jason thanks Steven, I'll be using a X509 certificate. will the custom X509SecurityTokenManager be called before decryption and signature verification? you mentioned 'since his private key is not valid so, the signature of his message won't be able to be verified', actually I think the hacker can send in a request signed with his valid private key, and since his public key is sent alone with the request, so WSE2 can verify the request signature successfully, true? does WSE2 called X509SecurityTokenManager to validate a certificate before verifying request signature? thanks, -Jason > Hi Jason, > [quoted text clipped - 66 lines] > thanks, > -Jason Hi Jason, The WSE2 will call X509SecurityTokenManager when find X509SecurityToken in the request Message's Security Context. However, the default implementation of the verification is doing nothing, we can override it to do our custom verification task (you can refer to the WSE2 's documentatin). Also, for the hack which replace the message with the one signed by its own private key, the problem is that he can not passed the authentication (suppose we use Certificate authentication), since the hacker dosn't have the valid x509 certificate which is used to identitfy him, he won't pass the authentication at serverside , event no need to consider the sequential decrypte and signature validation process. On the internet , a secure channel include three elements: consistency, confidentiality and identification. And the identification is just used to determine the clientside's identity, generally we call this process "Authentication". So when we use X509 certificate token for auhenticaiton, we force the clientside to provide a server recoginzed certificate token which the hacker won't have. This certificate could be different from the one we used to sign or encrypt the message. 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: <O9Bv4TJvFHA.3236@TK2MSFTNGP14.phx.gbl> <TF7tg7MvFHA.780@TK2MSFTNGXA01.phx.gbl> Subject: Re: how can we restrict what certificate WSE will use? Date: Mon, 19 Sep 2005 18:26:01 -0400 Lines: 96 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: <OA5sekWvFHA.2072@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:4922 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements thanks Steven, I'll be using a X509 certificate. will the custom X509SecurityTokenManager be called before decryption and signature verification? you mentioned 'since his private key is not valid so, the signature of his message won't be able to be verified', actually I think the hacker can send in a request signed with his valid private key, and since his public key is sent alone with the request, so WSE2 can verify the request signature successfully, true? does WSE2 called X509SecurityTokenManager to validate a certificate before verifying request signature? thanks, -Jason > Hi Jason, > > As for the question on the X509 certificate verification in .net webservice > using WSE, here are some of my understanding and suggestions: > [quoted text clipped - 49 lines] > assume I'm hosting a webservice, I have 2 trusted clients consume my > webservice, each client will send in properly encrypted and signed request, > WSE will take care of decryption and verification of the signature, > everything works great. now there is a hacker, tries to consume my [quoted text clipped - 3 lines] > reaching my code where I verify it's a trusted client. as you can see, the > decryption and signature verify happens automatically before I can check if > it's a trusted client. > > my question is, is there a way I can short circuit this process so that I > can terminate the request before decryption/ signature verification happens? > thanks, > -Jason HI Steven, thanks for the reply, it's good to know that X509SecurityTokenManager is called when X509SecurityToken is found in the context. there seems to be some disconnections where you say 'the hacker dosn't have the valid x509 certificate which is used to identify him'. I think the hacker can buy a valid x509 from Verisign and use it to identify him when accessing the webservice, right? the scenario I'm talking about is not man in the middle attack, it's more like how to prevent unwanted clients to access the webservice. I guess the solution is to write a custom X509SecurityTokenManager to verify the request is from a trusted client. and only requests passed the custom X509SecurityTokenManager will be decrypted, requests didn't pass the custom X509SecurityTokenManager will not be decrypted by WSE2, even though it might be properly encrypted and signed. am I right about this process? thanks, -Jason > Hi Jason, > [quoted text clipped - 133 lines] > > thanks, > > -Jason Curious, I had the same question to myself yesterday. However in the context of a SsslStream and requiring client certs. In the callback I was thinking you would look up a table of authorized SubjectNames and throw exception if not found. Not sure if this pulls off the desired behavior or not in all cases. If it did, I would think the same thing could be used in your case. SignatureWilliam Stacey [MVP] > HI Steven, > thanks for the reply, it's good to know that X509SecurityTokenManager [quoted text clipped - 170 lines] >> > thanks, >> > -Jason I think that's what need to be done. throwing exception would be good enough i guess. > Curious, I had the same question to myself yesterday. However in the > context of a SsslStream and requiring client certs. In the callback I was [quoted text clipped - 177 lines] > >> > thanks, > >> > -Jason Hi Jason, I think we are about to be match :). Yes, the X509SecurityTokenManager will be used to verify the X509Tokens in the cilent request's security context. also, as I mentioned the default implementation is doing nothing so we need to define a derived class and customize the Verfiy method. Also, as for the =================== I think the hacker can buy a valid x509 from Verisign and use it to identify him when accessing the webservice, right? the scenario I'm talking about is not man in the middle attack, it's more like how to prevent unwanted clients to access the webservice. I guess the solution is to write a custom X509SecurityTokenManager to verify the request is from a trusted client. ==================== Yes, the hacker can by a valid X509 certificate, that means he can use that certificate to build a valid signature and encrypted data section. However, at serverside, our application need to add the code to verify whether that certificate is in the valid list of our application specific requirement, that's what the authenticaiton need to do, also what we can do through use our custom SecurityTokenManager. 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: <O9Bv4TJvFHA.3236@TK2MSFTNGP14.phx.gbl> <TF7tg7MvFHA.780@TK2MSFTNGXA01.phx.gbl> <OA5sekWvFHA.2072@TK2MSFTNGP14.phx.gbl> <aeRnsfcvFHA.580@TK2MSFTNGXA01.phx.gbl> Subject: Re: how can we restrict what certificate WSE will use? Date: Tue, 20 Sep 2005 12:30:50 -0400 Lines: 174 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: <e6xKqCgvFHA.2948@TK2MSFTNGP15.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!TK2MSFTNGP15.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4928 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements HI Steven, thanks for the reply, it's good to know that X509SecurityTokenManager is called when X509SecurityToken is found in the context. there seems to be some disconnections where you say 'the hacker dosn't have the valid x509 certificate which is used to identify him'. I think the hacker can buy a valid x509 from Verisign and use it to identify him when accessing the webservice, right? the scenario I'm talking about is not man in the middle attack, it's more like how to prevent unwanted clients to access the webservice. I guess the solution is to write a custom X509SecurityTokenManager to verify the request is from a trusted client. and only requests passed the custom X509SecurityTokenManager will be decrypted, requests didn't pass the custom X509SecurityTokenManager will not be decrypted by WSE2, even though it might be properly encrypted and signed. am I right about this process? thanks, -Jason > Hi Jason, > > The WSE2 will call X509SecurityTokenManager when find X509SecurityToken in > the request Message's Security Context. However, the default implementation > of the verification is doing nothing, we can override it to do our custom > verification task (you can refer to the WSE2 's documentatin). Also, for [quoted text clipped - 46 lines] > you mentioned 'since his private key is not valid so, the signature of his > message won't be able to be verified', actually I think the hacker can send > in a request signed with his valid private key, and since his public key is > sent alone with the request, so WSE2 can verify the request signature > successfully, true? [quoted text clipped - 70 lines] > > automatically decrypt it and verify the signature successfully before > > reaching my code where I verify it's a trusted client. as you can see, the > > decryption and signature verify happens automatically before I can check > if [quoted text clipped - 6 lines] > > thanks, > > -Jason matched. thanks :) > Hi Jason, > [quoted text clipped - 213 lines] > > > thanks, > > > -Jason You're welcome Jason, 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: <O9Bv4TJvFHA.3236@TK2MSFTNGP14.phx.gbl> <TF7tg7MvFHA.780@TK2MSFTNGXA01.phx.gbl> <OA5sekWvFHA.2072@TK2MSFTNGP14.phx.gbl> <aeRnsfcvFHA.580@TK2MSFTNGXA01.phx.gbl> <e6xKqCgvFHA.2948@TK2MSFTNGP15.phx.gbl> <WZawyLmvFHA.1364@TK2MSFTNGXA01.phx.gbl> Subject: Re: how can we restrict what certificate WSE will use? Date: Wed, 21 Sep 2005 11:28:16 -0400 Lines: 262 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: <eG$qXEsvFHA.2056@TK2MSFTNGP10.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!TK2MSFTNGP10.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4945 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements matched. thanks :) > Hi Jason, > > I think we are about to be match :). Yes, the X509SecurityTokenManager > will be used to verify the X509Tokens in the cilent request's security > context. also, as I mentioned the default implementation is doing nothing > so we need to define a derived class and customize the Verfiy method. Also, > as for the > [quoted text clipped - 8 lines] > > Yes, the hacker can by a valid X509 certificate, that means he can use that > certificate to build a valid signature and encrypted data section. However, > at serverside, our application need to add the code to verify whether that > certificate is in the valid list of our application specific requirement, [quoted text clipped - 33 lines] > HI Steven, > thanks for the reply, it's good to know that X509SecurityTokenManager is > called when X509SecurityToken is found in the context. > there seems to be some disconnections where you say 'the hacker dosn't have > the valid x509 certificate which is used to identify him'. I think the > hacker can buy a valid x509 from Verisign and use it to identify him when [quoted text clipped - 4 lines] > and only requests passed the custom X509SecurityTokenManager will be > decrypted, requests didn't pass the custom X509SecurityTokenManager will not > be decrypted by WSE2, even though it might be properly encrypted and signed. > am I right about this process? > [quoted text clipped - 6 lines] > > > > The WSE2 will call X509SecurityTokenManager when find X509SecurityToken in > > the request Message's Security Context. However, the default > implementation > > of the verification is doing nothing, we can override it to do our custom > > verification task (you can refer to the WSE2 's documentatin). Also, for > > the hack which replace the message with the one signed by its own private > > key, the problem is that he can not passed the authentication (suppose we > > use Certificate authentication), since the hacker dosn't have the valid > > x509 certificate which is used to identitfy him, he won't pass the [quoted text clipped - 3 lines] > > > > consistency, confidentiality and identification. And the identification is > > just used to determine the clientside's identity, generally we call this > > process "Authentication". So when we use X509 certificate token for > > auhenticaiton, we force the clientside to provide a server recoginzed > > certificate token which the hacker won't have. This certificate could be > > different from the one we used to sign or encrypt the message. > > [quoted text clipped - 30 lines] > > signature verification? > > you mentioned 'since his private key is not valid so, the signature of his > > message won't be able to be verified', actually I think the hacker can > send [quoted text clipped - 3 lines] > > successfully, true? > > does WSE2 called X509SecurityTokenManager to validate a certificate before > > verifying request signature? > > [quoted text clipped - 10 lines] > > > message, it's ok. However, since his private key is not valid so, the > > > signature of his message won't be able to be verified at the serverside. > > > Also, we must have authentication protection at serverside through > > > securityTokens(UsernameToken or X509CertificateToken ...). So are you > > > using X509CertificateToken for authentication? If so you can consider > > > defining a custom TokenManager class for X509Certificate Authentication. > > > We can create such a class which dervied from the > > > > > > Microsoft.Web.Services2.Security.Tokens.X509SecurityTokenManager class > > > This class has a "AuthenticateToken" method > > > [quoted text clipped - 5 lines] > > > override this method in our custom manager class to do our own verfiy > > > processing. Also, you can search the class in the WSE documentation and > > > there're also reference on our to register custom Token Manager class > > > within service's config file. [quoted text clipped - 31 lines] > > > everything works great. now there is a hacker, tries to consume my > > > webservice, he encrypted his request using my public key, and signed his > > > request using his own private key, when I received the request WSE will > > > automatically decrypt it and verify the signature successfully before > > > reaching my code where I verify it's a trusted client. as you can see, > the > > > decryption and signature verify happens automatically before I can check > > if > > > it's a trusted client. > > > > > > my question is, is there a way I can short circuit this process so that > I > > > can terminate the request before decryption/ signature verification > > happens? > > > > > > thanks, > > > -Jason > Hi Jason, > [quoted text clipped - 28 lines] > (This posting is provided "AS IS", with no warranties, and confers no > rights.) Instead of a custom SecurityTokenManager we could for instance get the Token.KeyIdentifier and match it with the value from DB. The "hacker" even with a valid certificate would not have his keyidentifier in the DB so he wouldn't be able to do anything. This is what i'm doing and that's what the X509Signing sample (from WSE 2.0 package) is doing. Is this a good idea? or should we use the SecurityTokenManager?
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.