Re: how can we restrict what certificate WSE will use?

{\rtf1\ansi\ansicpg936\deff0\deflang1033\deflangfe2052{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\lang2052\f0\fs20 Hi Jason,
\par
\par 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
\par
\par ===================
\par I think the
\par hacker can buy a valid x509 from Verisign and use it to identify him when
\par accessing the webservice, right? the scenario I'm talking about is not man
\par in the middle attack, it's more like how to prevent unwanted clients to
\par access the webservice. I guess the solution is to write a custom
\par X509SecurityTokenManager to verify the request is from a trusted client.
\par ====================
\par
\par 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.
\par
\par Thanks,
\par
\par Steven Cheng
\par Microsoft Online Support
\par
\par Get Secure! www.microsoft.com/security
\par (This posting is provided "AS IS", with no warranties, and confers no rights.)
\par
\par
\par
\par
\par \pard\li720 --------------------
\par From: <jason.chen@xxxxxxxxxxxxxxxxx>
\par References: <O9Bv4TJvFHA.3236@xxxxxxxxxxxxxxxxxxxx> <TF7tg7MvFHA.780@xxxxxxxxxxxxxxxxxxxxx> <OA5sekWvFHA.2072@xxxxxxxxxxxxxxxxxxxx> <aeRnsfcvFHA.580@xxxxxxxxxxxxxxxxxxxxx>
\par Subject: Re: how can we restrict what certificate WSE will use?
\par Date: Tue, 20 Sep 2005 12:30:50 -0400
\par Lines: 174
\par X-Priority: 3
\par X-MSMail-Priority: Normal
\par X-Newsreader: Microsoft Outlook Express 6.00.3790.326
\par X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326
\par Message-ID: <e6xKqCgvFHA.2948@xxxxxxxxxxxxxxxxxxxx>
\par Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements
\par NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3
\par Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP15.phx.gbl
\par Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices.enhancements:4928
\par X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements
\par
\par HI Steven,
\par thanks for the reply, it's good to know that X509SecurityTokenManager is
\par called when X509SecurityToken is found in the context.
\par there seems to be some disconnections where you say 'the hacker dosn't have
\par the valid x509 certificate which is used to identify him'. I think the
\par hacker can buy a valid x509 from Verisign and use it to identify him when
\par accessing the webservice, right? the scenario I'm talking about is not man
\par in the middle attack, it's more like how to prevent unwanted clients to
\par access the webservice. I guess the solution is to write a custom
\par X509SecurityTokenManager to verify the request is from a trusted client.
\par and only requests passed the custom X509SecurityTokenManager will be
\par decrypted, requests didn't pass the custom X509SecurityTokenManager will not
\par be decrypted by WSE2, even though it might be properly encrypted and signed.
\par
\par am I right about this process?
\par
\par thanks,
\par -Jason
\par
\par "Steven Cheng[MSFT]" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
\par news:aeRnsfcvFHA.580@xxxxxxxxxxxxxxxxxxxxxxxx
\par > Hi Jason,
\par >
\par > The WSE2 will call X509SecurityTokenManager when find X509SecurityToken in
\par > the request Message's Security Context. However, the default
\par implementation
\par > of the verification is doing nothing, we can override it to do our custom
\par > verification task (you can refer to the WSE2 's documentatin). Also, for
\par > the hack which replace the message with the one signed by its own private
\par > key, the problem is that he can not passed the authentication (suppose we
\par > use Certificate authentication), since the hacker dosn't have the valid
\par > x509 certificate which is used to identitfy him, he won't pass the
\par > authentication at serverside , event no need to consider the sequential
\par > decrypte and signature validation process. On the internet , a secure
\par > channel include three elements:
\par >
\par > consistency, confidentiality and identification. And the identification is
\par > just used to determine the clientside's identity, generally we call this
\par > process "Authentication". So when we use X509 certificate token for
\par > auhenticaiton, we force the clientside to provide a server recoginzed
\par > certificate token which the hacker won't have. This certificate could be
\par > different from the one we used to sign or encrypt the message.
\par >
\par > Thanks,
\par >
\par > Steven Cheng
\par > Microsoft Online Support
\par >
\par > Get Secure! www.microsoft.com/security
\par > (This posting is provided "AS IS", with no warranties, and confers no
\par > rights.)
\par >
\par > --------------------
\par > From: <jason.chen@xxxxxxxxxxxxxxxxx>
\par > References: <O9Bv4TJvFHA.3236@xxxxxxxxxxxxxxxxxxxx>
\par > <TF7tg7MvFHA.780@xxxxxxxxxxxxxxxxxxxxx>
\par > Subject: Re: how can we restrict what certificate WSE will use?
\par > Date: Mon, 19 Sep 2005 18:26:01 -0400
\par > Lines: 96
\par > X-Priority: 3
\par > X-MSMail-Priority: Normal
\par > X-Newsreader: Microsoft Outlook Express 6.00.3790.326
\par > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326
\par > Message-ID: <OA5sekWvFHA.2072@xxxxxxxxxxxxxxxxxxxx>
\par > Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements
\par > NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3
\par > Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14.phx.gbl
\par > Xref: TK2MSFTNGXA01.phx.gbl
\par > microsoft.public.dotnet.framework.webservices.enhancements:4922
\par > X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements
\par >
\par > thanks Steven, I'll be using a X509 certificate.
\par > will the custom X509SecurityTokenManager be called before decryption and
\par > signature verification?
\par > you mentioned 'since his private key is not valid so, the signature of his
\par > message won't be able to be verified', actually I think the hacker can
\par send
\par > in a request signed with his valid private key, and since his public key
\par is
\par > sent alone with the request, so WSE2 can verify the request signature
\par > successfully, true?
\par > does WSE2 called X509SecurityTokenManager to validate a certificate before
\par > verifying request signature?
\par >
\par > thanks,
\par > -Jason
\par >
\par > "Steven Cheng[MSFT]" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
\par > news:TF7tg7MvFHA.780@xxxxxxxxxxxxxxxxxxxxxxxx
\par > > Hi Jason,
\par > >
\par > > As for the question on the X509 certificate verification in .net
\par > webservice
\par > > using WSE, here are some of my understanding and suggestions:
\par > >
\par > > When a hacker use your public key (server certificate) to encrypte the
\par > > message, it's ok. However, since his private key is not valid so, the
\par > > signature of his message won't be able to be verified at the serverside.
\par > > Also, we must have authentication protection at serverside through
\par > > securityTokens(UsernameToken or X509CertificateToken ...). So are you
\par > > using X509CertificateToken for authentication? If so you can consider
\par > > defining a custom TokenManager class for X509Certificate Authentication.
\par > > We can create such a class which dervied from the
\par > >
\par > > Microsoft.Web.Services2.Security.Tokens.X509SecurityTokenManager class
\par > >
\par > > This class has a "AuthenticateToken" method
\par > >
\par > > protected virtual void AuthenticateToken(
\par > > X509SecurityToken token
\par > > );
\par > >
\par > > which is used to verify the clientside x509certificate token, we can
\par > > override this method in our custom manager class to do our own verfiy
\par > > processing. Also, you can search the class in the WSE documentation and
\par > > there're also reference on our to register custom Token Manager class
\par > > within service's config file.
\par > >
\par > > Thanks,
\par > >
\par > > Steven Cheng
\par > > Microsoft Online Support
\par > >
\par > > Get Secure! www.microsoft.com/security
\par > > (This posting is provided "AS IS", with no warranties, and confers no
\par > > rights.)
\par > >
\par > >
\par > > --------------------
\par > > From: <jason.chen@xxxxxxxxxxxxxxxxx>
\par > > Subject: how can we restrict what certificate WSE will use?
\par > > Date: Sun, 18 Sep 2005 17:07:24 -0400
\par > > Lines: 18
\par > > X-Priority: 3
\par > > X-MSMail-Priority: Normal
\par > > X-Newsreader: Microsoft Outlook Express 6.00.3790.326
\par > > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326
\par > > Message-ID: <O9Bv4TJvFHA.3236@xxxxxxxxxxxxxxxxxxxx>
\par > > Newsgroups: microsoft.public.dotnet.framework.webservices.enhancements
\par > > NNTP-Posting-Host: a7cebc03.cst.lightpath.net 167.206.188.3
\par > > Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14.phx.gbl
\par > > Xref: TK2MSFTNGXA01.phx.gbl
\par > > microsoft.public.dotnet.framework.webservices.enhancements:4914
\par > > X-Tomcat-NG: microsoft.public.dotnet.framework.webservices.enhancements
\par > >
\par > > assume I'm hosting a webservice, I have 2 trusted clients consume my
\par > > webservice, each client will send in properly encrypted and signed
\par > request,
\par > > WSE will take care of decryption and verification of the signature,
\par > > everything works great. now there is a hacker, tries to consume my
\par > > webservice, he encrypted his request using my public key, and signed his
\par > > request using his own private key, when I received the request WSE will
\par > > automatically decrypt it and verify the signature successfully before
\par > > reaching my code where I verify it's a trusted client. as you can see,
\par the
\par > > decryption and signature verify happens automatically before I can check
\par > if
\par > > it's a trusted client.
\par > >
\par > > my question is, is there a way I can short circuit this process so that
\par I
\par > > can terminate the request before decryption/ signature verification
\par > happens?
\par > >
\par > > thanks,
\par > > -Jason
\par > >
\par > >
\par > >
\par >
\par >
\par >
\par
\par
\par \pard
\par
\par }