Need for encryption in WSE 3.0 if using SS-avoid man-in-middle att

Discussion in 'ASP .Net Security' started by John K, Oct 17, 2006.

  1. John K

    John K Guest

    Hello.

    I plan on upgrading my .NET 2.0 web service to use WSE 3.0. I am using my
    web service over SSL and the PC client application access the web service
    directly (no middle man server(s)). I will be adding the UserNameToken
    option to authenticate the user to the web service. I am considering adding
    "usernameForCertificateSecurity" for additional security; even though I am
    also using SSL. I am concerned about "man in the middle" attacks for both
    the password and data being sent back and forth. How do I decide if SSL is
    sufficient? Is the password sent in an encrypted format if I only use
    "usernameOverTransport Security"? Is it possible for someone to find out the
    password that the PC sends for authentication to the web service if I only
    use "usernameOverTransport Security"? If it is possible to see someone's
    password; what's a good way to verify the PC application is "talking" to a
    valid server before it tries to authenticate by sending the user ID/Password?
    --
    Thank you.
    John K, Oct 17, 2006
    #1
    1. Advertising

  2. SSL is not prone to MITM attacks. You don't need additional message based
    security.

    SSL also does server authentication by default. Before you send data, the
    client checks the server certificate which has to be trusted and the common
    name must match the DNS name portion of the URL.

    http://www.google.com/search?q=how ...-us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1

    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > Hello.
    >
    > I plan on upgrading my .NET 2.0 web service to use WSE 3.0. I am
    > using my web service over SSL and the PC client application access the
    > web service directly (no middle man server(s)). I will be adding the
    > UserNameToken option to authenticate the user to the web service. I
    > am considering adding "usernameForCertificateSecurity" for additional
    > security; even though I am also using SSL. I am concerned about "man
    > in the middle" attacks for both the password and data being sent back
    > and forth. How do I decide if SSL is sufficient? Is the password
    > sent in an encrypted format if I only use "usernameOverTransport
    > Security"? Is it possible for someone to find out the password that
    > the PC sends for authentication to the web service if I only use
    > "usernameOverTransport Security"? If it is possible to see someone's
    > password; what's a good way to verify the PC application is "talking"
    > to a valid server before it tries to authenticate by sending the user
    > ID/Password?
    >
    Dominick Baier, Oct 17, 2006
    #2
    1. Advertising

  3. John K

    John K Guest

    Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    The web address my PC client program goes to for the web services is editable
    by the user. This is in case the customer wants to host the server side
    components on their own server. Thus they need the ability to change the
    address. Thus, some malicious user could change the address to some other
    server with an SSL certificate. Then an unknowing, authorized user could
    attempt to log into the web site with the PC client program, thinking its the
    correct one since they don't know someone changed it (i.e. like a physical
    key stroke logger hardware). The PC client program would then go to
    authorize, unfortuantely to the wrong server; would then malicious server see
    the user's password if I only use usernameOvertransportSecurity? I would
    think the PC client would send the password unencrypted, but I am not sure if
    it is still encrypted with that setting.
    --
    Thank you.


    "Dominick Baier" wrote:

    > SSL is not prone to MITM attacks. You don't need additional message based
    > security.
    >
    > SSL also does server authentication by default. Before you send data, the
    > client checks the server certificate which has to be trusted and the common
    > name must match the DNS name portion of the URL.
    >
    > http://www.google.com/search?q=how ...-us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    > > Hello.
    > >
    > > I plan on upgrading my .NET 2.0 web service to use WSE 3.0. I am
    > > using my web service over SSL and the PC client application access the
    > > web service directly (no middle man server(s)). I will be adding the
    > > UserNameToken option to authenticate the user to the web service. I
    > > am considering adding "usernameForCertificateSecurity" for additional
    > > security; even though I am also using SSL. I am concerned about "man
    > > in the middle" attacks for both the password and data being sent back
    > > and forth. How do I decide if SSL is sufficient? Is the password
    > > sent in an encrypted format if I only use "usernameOverTransport
    > > Security"? Is it possible for someone to find out the password that
    > > the PC sends for authentication to the web service if I only use
    > > "usernameOverTransport Security"? If it is possible to see someone's
    > > password; what's a good way to verify the PC application is "talking"
    > > to a valid server before it tries to authenticate by sending the user
    > > ID/Password?
    > >

    >
    >
    >
    John K, Oct 17, 2006
    #3
  4. Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    if the other endpoint has a trusted and valid SSL certificate, he would see
    the data in cleartext.

    But if you let customers change the endpoint address they must be also able
    to change the server certificate for mutual authentication..so i don't see
    a real advantage to use additional message security - and you are in the
    same situation as with transport security.

    Make sure that only authorized people (e.g. an admin) can change URIs on
    the client.

    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > The web address my PC client program goes to for the web services is
    > editable by the user. This is in case the customer wants to host the
    > server side components on their own server. Thus they need the
    > ability to change the address. Thus, some malicious user could change
    > the address to some other server with an SSL certificate. Then an
    > unknowing, authorized user could attempt to log into the web site with
    > the PC client program, thinking its the correct one since they don't
    > know someone changed it (i.e. like a physical key stroke logger
    > hardware). The PC client program would then go to authorize,
    > unfortuantely to the wrong server; would then malicious server see the
    > user's password if I only use usernameOvertransportSecurity? I would
    > think the PC client would send the password unencrypted, but I am not
    > sure if it is still encrypted with that setting.
    >
    > "Dominick Baier" wrote:
    >
    >> SSL is not prone to MITM attacks. You don't need additional message
    >> based security.
    >>
    >> SSL also does server authentication by default. Before you send data,
    >> the client checks the server certificate which has to be trusted and
    >> the common name must match the DNS name portion of the URL.
    >>
    >> http://www.google.com/search?q=how does ssl work&rls=com.microsoft:en
    >> -us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1
    >>
    >> ---
    >> Dominick Baier, DevelopMentor
    >> http://www.leastprivilege.com
    >>> Hello.
    >>>
    >>> I plan on upgrading my .NET 2.0 web service to use WSE 3.0. I am
    >>> using my web service over SSL and the PC client application access
    >>> the web service directly (no middle man server(s)). I will be
    >>> adding the UserNameToken option to authenticate the user to the web
    >>> service. I am considering adding "usernameForCertificateSecurity"
    >>> for additional security; even though I am also using SSL. I am
    >>> concerned about "man in the middle" attacks for both the password
    >>> and data being sent back and forth. How do I decide if SSL is
    >>> sufficient? Is the password sent in an encrypted format if I only
    >>> use "usernameOverTransport Security"? Is it possible for someone to
    >>> find out the password that the PC sends for authentication to the
    >>> web service if I only use "usernameOverTransport Security"? If it
    >>> is possible to see someone's password; what's a good way to verify
    >>> the PC application is "talking" to a valid server before it tries to
    >>> authenticate by sending the user ID/Password?
    >>>
    Dominick Baier, Oct 18, 2006
    #4
  5. Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    Hi John,

    If you only applied SSL/https as the transport channel and not use message
    layer security feature in WSE, WSE will certainly send out the soap message
    (include username/password credentials) in clearText format. However, I
    think SSL/HTTPS should be strong enough for secure the mesages transfering
    over the transport layer. If your concern is that some malicious one else
    may redirect the request to a fake server with SSL/certificates, then you
    can add codelogic in your client application to valiate the server
    certificate exposed from the SSL/HTTPS server. The ServicePointManager
    class in .net framework provide ServerCertificateValidationCallback event
    that can let us add custom code logic to verify the server (which provide
    the SSL/HTTPS service channel). And this event will occur at the initial
    time when your webservice (or other webclient) which connect to HTTPS/SSL
    server through .net webrequest components:


    #ServicePointManager.ServerCertificateValidationCallback Property
    http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
    ercertificatevalidationcallback.aspx

    #RemoteCertificateValidationCallback Delegate
    http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
    tevalidationcallback.aspx


    Anyway, I also think that you can choose either
    SSL/HTTPS(UsernameOverTransport) or message layer
    security(UsernameOverCertificate), use both of them may be a bit redundant.

    Please feel free to post here if you have any other concerns or ideas on
    this.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Oct 18, 2006
    #5
  6. John K

    John K Guest

    Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    How do I perform mutual authentication; in particular, how can my application
    verify it is talking to the right server before it tries to log into the web
    service? Is this done with certificates (private on server and public
    version of it on client)? I already have an SSL certificate from Verisign
    for the server. Do I generate a "public" certificate based on that server
    (private) certificate and then distribute it with the app and then the app.
    verifies the certificates are for the same server? Is there an article with
    an example on how to do this? I want to make sure I don't talk to a malicous
    server and give it the password without first verifying it is a valid server.
    Remember that my application needs the ability to change what server it
    points to.
    --
    Thank you.


    "Dominick Baier" wrote:

    > if the other endpoint has a trusted and valid SSL certificate, he would see
    > the data in cleartext.
    >
    > But if you let customers change the endpoint address they must be also able
    > to change the server certificate for mutual authentication..so i don't see
    > a real advantage to use additional message security - and you are in the
    > same situation as with transport security.
    >
    > Make sure that only authorized people (e.g. an admin) can change URIs on
    > the client.
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    > > The web address my PC client program goes to for the web services is
    > > editable by the user. This is in case the customer wants to host the
    > > server side components on their own server. Thus they need the
    > > ability to change the address. Thus, some malicious user could change
    > > the address to some other server with an SSL certificate. Then an
    > > unknowing, authorized user could attempt to log into the web site with
    > > the PC client program, thinking its the correct one since they don't
    > > know someone changed it (i.e. like a physical key stroke logger
    > > hardware). The PC client program would then go to authorize,
    > > unfortuantely to the wrong server; would then malicious server see the
    > > user's password if I only use usernameOvertransportSecurity? I would
    > > think the PC client would send the password unencrypted, but I am not
    > > sure if it is still encrypted with that setting.
    > >
    > > "Dominick Baier" wrote:
    > >
    > >> SSL is not prone to MITM attacks. You don't need additional message
    > >> based security.
    > >>
    > >> SSL also does server authentication by default. Before you send data,
    > >> the client checks the server certificate which has to be trusted and
    > >> the common name must match the DNS name portion of the URL.
    > >>
    > >> http://www.google.com/search?q=how does ssl work&rls=com.microsoft:en
    > >> -us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1
    > >>
    > >> ---
    > >> Dominick Baier, DevelopMentor
    > >> http://www.leastprivilege.com
    > >>> Hello.
    > >>>
    > >>> I plan on upgrading my .NET 2.0 web service to use WSE 3.0. I am
    > >>> using my web service over SSL and the PC client application access
    > >>> the web service directly (no middle man server(s)). I will be
    > >>> adding the UserNameToken option to authenticate the user to the web
    > >>> service. I am considering adding "usernameForCertificateSecurity"
    > >>> for additional security; even though I am also using SSL. I am
    > >>> concerned about "man in the middle" attacks for both the password
    > >>> and data being sent back and forth. How do I decide if SSL is
    > >>> sufficient? Is the password sent in an encrypted format if I only
    > >>> use "usernameOverTransport Security"? Is it possible for someone to
    > >>> find out the password that the PC sends for authentication to the
    > >>> web service if I only use "usernameOverTransport Security"? If it
    > >>> is possible to see someone's password; what's a good way to verify
    > >>> the PC application is "talking" to a valid server before it tries to
    > >>> authenticate by sending the user ID/Password?
    > >>>

    >
    >
    >
    John K, Oct 18, 2006
    #6
  7. Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    Hello John,

    If you use WSE message layer security, the "mutualCertificate10" and
    "mutualCertificate11" will both support mutual authentication againt both
    server and client.

    As for transport layer secruity through SSL/HTTPS, as I mentioned in the
    last reply, you can add code logic in your webservice client and hook the
    Server Certificate validation process to determine whether the https/SSL
    server is a valid and expected server.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Oct 19, 2006
    #7
  8. John K

    John K Guest

    Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    Dominick said I don't need message level security since I am using SSL, thus
    message level security adds unnecessary overhead. Is there a good way to do
    mutual authentication at first connection to the web service so there is no
    signficant overhead for message based security? Is there any "how to" or
    examples on how to implement mutual authentication, ideally, without
    requiring message based security? Finally, if I do need a client certificate
    to do the mutual authentication; how do I generate a client certificate? Can
    I generate a client certificate from a server SSL certificate (which my
    server has) OR do I need another type of certificate on my server.

    I know there are several questions here, but please answer each one.
    --
    Thank you.


    "Steven Cheng[MSFT]" wrote:

    > Hello John,
    >
    > If you use WSE message layer security, the "mutualCertificate10" and
    > "mutualCertificate11" will both support mutual authentication againt both
    > server and client.
    >
    > As for transport layer secruity through SSL/HTTPS, as I mentioned in the
    > last reply, you can add code logic in your webservice client and hook the
    > Server Certificate validation process to determine whether the https/SSL
    > server is a valid and expected server.
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
    >
    >
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
    John K, Oct 19, 2006
    #8
  9. Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    > SSL, thus message level security adds unnecessary overhead. Is there
    > a good way to do mutual authentication at first connection to the web
    > service so there is no signficant overhead for message based security?


    thats _exactly_ what SSL is doing.

    for client certificate authentication, simply require SSL client certificates
    in IIS (directory security tab).

    > Finally, if I do need a client certificate to do the mutual
    > authentication; how do I generate a client certificate? Can I


    You can use a public CA or Windows Certificate Services or makercert.exe



    ---
    Dominick Baier, DevelopMentor
    http://www.leastprivilege.com

    > Dominick said I don't need message level security since I am using
    > SSL, thus message level security adds unnecessary overhead. Is there
    > a good way to do mutual authentication at first connection to the web
    > service so there is no signficant overhead for message based security?
    > Is there any "how to" or examples on how to implement mutual
    > authentication, ideally, without requiring message based security?
    > Finally, if I do need a client certificate to do the mutual
    > authentication; how do I generate a client certificate? Can I
    > generate a client certificate from a server SSL certificate (which my
    > server has) OR do I need another type of certificate on my server.
    >
    > I know there are several questions here, but please answer each one.
    >
    > "Steven Cheng[MSFT]" wrote:
    >
    >> Hello John,
    >>
    >> If you use WSE message layer security, the "mutualCertificate10" and
    >> "mutualCertificate11" will both support mutual authentication againt
    >> both server and client.
    >>
    >> As for transport layer secruity through SSL/HTTPS, as I mentioned in
    >> the last reply, you can add code logic in your webservice client and
    >> hook the Server Certificate validation process to determine whether
    >> the https/SSL server is a valid and expected server.
    >>
    >> Sincerely,
    >>
    >> Steven Cheng
    >>
    >> Microsoft MSDN Online Support Lead
    >>
    >> This posting is provided "AS IS" with no warranties, and confers no
    >> rights.
    >>
    Dominick Baier, Oct 19, 2006
    #9
  10. John K

    John K Guest

    Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    SSL only validates you are talking to a SSL certified server; not necessarily
    the "right" SSL certified server. We allow the client user to change what
    URL the software uses for accessing web services. This is our customer wants
    to host the server components of the system we are selling on their server(s)
    instead of ours. Thus, we do not need to send a special version of the
    software to the customer. They can simply edit the URL the client program
    access.

    Thus, I am wondering what is a secure way of verifying the client program is
    talking to a "valid" server (the one with the acutal web services that need
    to be accessed) BEFORE it sends the user's ID and password. I believe this
    can be done by using a X.509 certificate on both ends, but I thought the adds
    message level security which is overkill since we are using SSL. What do you
    recommend for testing if the client program is talking to the "right" server
    before it freely gives the user ID and password for authentication. Since we
    allow the user to change the URL in the client program; a malicous user could
    temporarily change the URL and then an unsuspecting user would attempt to log
    in and when the S/W tries to do that; it would give the "malicious" server
    it's password.
    --
    Thank you.


    "Dominick Baier" wrote:

    > > SSL, thus message level security adds unnecessary overhead. Is there
    > > a good way to do mutual authentication at first connection to the web
    > > service so there is no signficant overhead for message based security?

    >
    > thats _exactly_ what SSL is doing.
    >
    > for client certificate authentication, simply require SSL client certificates
    > in IIS (directory security tab).
    >
    > > Finally, if I do need a client certificate to do the mutual
    > > authentication; how do I generate a client certificate? Can I

    >
    > You can use a public CA or Windows Certificate Services or makercert.exe
    >
    >
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    > > Dominick said I don't need message level security since I am using
    > > SSL, thus message level security adds unnecessary overhead. Is there
    > > a good way to do mutual authentication at first connection to the web
    > > service so there is no signficant overhead for message based security?
    > > Is there any "how to" or examples on how to implement mutual
    > > authentication, ideally, without requiring message based security?
    > > Finally, if I do need a client certificate to do the mutual
    > > authentication; how do I generate a client certificate? Can I
    > > generate a client certificate from a server SSL certificate (which my
    > > server has) OR do I need another type of certificate on my server.
    > >
    > > I know there are several questions here, but please answer each one.
    > >
    > > "Steven Cheng[MSFT]" wrote:
    > >
    > >> Hello John,
    > >>
    > >> If you use WSE message layer security, the "mutualCertificate10" and
    > >> "mutualCertificate11" will both support mutual authentication againt
    > >> both server and client.
    > >>
    > >> As for transport layer secruity through SSL/HTTPS, as I mentioned in
    > >> the last reply, you can add code logic in your webservice client and
    > >> hook the Server Certificate validation process to determine whether
    > >> the https/SSL server is a valid and expected server.
    > >>
    > >> Sincerely,
    > >>
    > >> Steven Cheng
    > >>
    > >> Microsoft MSDN Online Support Lead
    > >>
    > >> This posting is provided "AS IS" with no warranties, and confers no
    > >> rights.
    > >>

    >
    >
    >
    John K, Oct 19, 2006
    #10
  11. Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    Hi John,

    Yes, your concern that some malicious user may redirect the user to a fake
    server is reasonable. However, this can be detected by SSL/HTTPS client in
    almost every webclient implementation. For example, in IE browser, when
    you visit a ssl/https protected site, if the server certificate is not in
    your client machine's trust storage, IE will raise dialog to alert you and
    only if you proof to continue will the https/ssl connection successfully
    establish.

    When you use .net network API(such as webservice proxy or webrequest class)
    to access remote SSL/https service, there also exist programming interface
    to do the validation. I've mentioned the
    "ServicePointManager.ServerCertificateValidationCallback" event in my first
    reply, is there any particular reason or difficulty that this is not
    suitable in your scenario?

    This event is firing everytime at the initialize time of a https/ssl
    connection between client and server(when the client just receive server's
    SSL certificate), you can query the certificate's attributes to determine
    whether it is your expected one(this validation logic is up to you since
    you know what certificate is expected ....). Surely, at that time, the
    webservice hasn't send any message since SSL/HTTPS connection is even not
    established, if you found that the server certificate is not expected one,
    just return false for the function or even through exception.

    Here is my original message in first reply
    ==============================
    If your concern is that some malicious one else may redirect the request
    to a fake server with SSL/certificates, then you can add codelogic in your
    client application to valiate the server certificate exposed from the
    SSL/HTTPS server. The ServicePointManager class in .net framework provide
    ServerCertificateValidationCallback event that can let us add custom code
    logic to verify the server (which provide the SSL/HTTPS service hannel).
    And this event will occur at the initial time when your webservice (or
    other webclient) which connect to HTTPS/SSL server through .net webrequest
    components:


    #ServicePointManager.ServerCertificateValidationCallback Property
    http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
    ercertificatevalidationcallback.aspx

    #RemoteCertificateValidationCallback Delegate
    http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
    tevalidationcallback.aspx
    =============================

    Anyway, I think https/ssl the prefered approach if possible since it is
    much simpler and strong for secure channel over http.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Oct 20, 2006
    #11
  12. John K

    John K Guest

    Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    The part that is confusing for me is the fact that we are allowing the user
    to change the URL. Thus, correct me if I am wrong, in this scenario; in
    order to detect we are connected to the wrong server (even though its SSL
    certificate is OK and valid by Verisign); we would need a client certificate.
    Correct? If so, as I asked in a few messages, how do I generate a client
    certificate? Can I generate a matching client certificate from the server's
    SSL certificate OR do I need another set of certificates (a client and
    server)? Are there any articles that go into detail on how to verify you are
    talking to the right server. Again, in my case my customer may host the
    server application; thus when I write the client S/W; I have no idea as to
    what server is valid. It sounds like verifying the public certificate at the
    client end matches the server certificate is the way to go. Do you have any
    tips to what to look for in the certificate's attributes in this scenario?
    Do I simply verify my client certificate is the public version of the
    server's certificate and thus that means I am talking to the right server?
    Thus, the customer could simply just place the public version of the server's
    certificate in our client application directory? Thanks alot. I am new to
    this and just want to make sure I have a secure application.
    --
    Thank you.


    "Steven Cheng[MSFT]" wrote:

    > Hi John,
    >
    > Yes, your concern that some malicious user may redirect the user to a fake
    > server is reasonable. However, this can be detected by SSL/HTTPS client in
    > almost every webclient implementation. For example, in IE browser, when
    > you visit a ssl/https protected site, if the server certificate is not in
    > your client machine's trust storage, IE will raise dialog to alert you and
    > only if you proof to continue will the https/ssl connection successfully
    > establish.
    >
    > When you use .net network API(such as webservice proxy or webrequest class)
    > to access remote SSL/https service, there also exist programming interface
    > to do the validation. I've mentioned the
    > "ServicePointManager.ServerCertificateValidationCallback" event in my first
    > reply, is there any particular reason or difficulty that this is not
    > suitable in your scenario?
    >
    > This event is firing everytime at the initialize time of a https/ssl
    > connection between client and server(when the client just receive server's
    > SSL certificate), you can query the certificate's attributes to determine
    > whether it is your expected one(this validation logic is up to you since
    > you know what certificate is expected ....). Surely, at that time, the
    > webservice hasn't send any message since SSL/HTTPS connection is even not
    > established, if you found that the server certificate is not expected one,
    > just return false for the function or even through exception.
    >
    > Here is my original message in first reply
    > ==============================
    > If your concern is that some malicious one else may redirect the request
    > to a fake server with SSL/certificates, then you can add codelogic in your
    > client application to valiate the server certificate exposed from the
    > SSL/HTTPS server. The ServicePointManager class in .net framework provide
    > ServerCertificateValidationCallback event that can let us add custom code
    > logic to verify the server (which provide the SSL/HTTPS service hannel).
    > And this event will occur at the initial time when your webservice (or
    > other webclient) which connect to HTTPS/SSL server through .net webrequest
    > components:
    >
    >
    > #ServicePointManager.ServerCertificateValidationCallback Property
    > http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
    > ercertificatevalidationcallback.aspx
    >
    > #RemoteCertificateValidationCallback Delegate
    > http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
    > tevalidationcallback.aspx
    > =============================
    >
    > Anyway, I think https/ssl the prefered approach if possible since it is
    > much simpler and strong for secure channel over http.
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
    >
    >
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
    John K, Oct 20, 2006
    #12
  13. Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    Thanks for your reply John,

    Well, now I understand the "client certificate" you mean, actually this
    should be called "public certificate of the server SSL/HTTPS certificate"
    (which only contains the public key to identitfy the server certificate).

    Yes, you can import such a public certificate of server-certificate into
    client machine's trusted storage so that the SSL/HTTPS server with the
    correct server certificate can be identified. However, this is not
    necessary because X509 certificate verification is based on certificate
    chain, so the client can correctly validate the certificate as long as the
    SSL/HTTPS certificate's CA's certificate is installed or any trusted super
    path certificates is installed into trusted storage.

    Also, even if your server certificate's public certificate is not
    installed, you still have chance to validate the certificate yourself in
    code. In .net you can use the
    "ServicePointManager.ServerCertificateValidationCallback" propertyto
    register such a callback delegate to check the certifiate your self, e.g

    =========================
    public static bool ValidateServerCertificate(
    object sender,
    X509Certificate certificate,
    X509Chain chain,
    SslPolicyErrors sslPolicyErrors)
    {
    if (sslPolicyErrors == SslPolicyErrors.None)
    {
    if (certificate.GetPublicKeyString() == xxxxx)
    {
    return true;
    }
    }


    return false;
    }
    =========================

    You can refer to the following MSDN reference for detailed info:

    #ServicePointManager.ServerCertificateValidationCallback Property
    http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
    ercertificatevalidationcallback.aspx


    #RemoteCertificateValidationCallback Delegate
    http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
    tevalidationcallback.aspx

    Please feel free to let me know if there is still anything unclear or
    anything I missed.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Oct 23, 2006
    #13
  14. John K

    John K Guest

    Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    Hello Steven,

    Is a X509 certificate, that you mentioned, a different certificate OR is it
    part of the server's SSL certificate? I thought they were entirely different
    things. --
    Thank you.


    "Steven Cheng[MSFT]" wrote:

    > Thanks for your reply John,
    >
    > Well, now I understand the "client certificate" you mean, actually this
    > should be called "public certificate of the server SSL/HTTPS certificate"
    > (which only contains the public key to identitfy the server certificate).
    >
    > Yes, you can import such a public certificate of server-certificate into
    > client machine's trusted storage so that the SSL/HTTPS server with the
    > correct server certificate can be identified. However, this is not
    > necessary because X509 certificate verification is based on certificate
    > chain, so the client can correctly validate the certificate as long as the
    > SSL/HTTPS certificate's CA's certificate is installed or any trusted super
    > path certificates is installed into trusted storage.
    >
    > Also, even if your server certificate's public certificate is not
    > installed, you still have chance to validate the certificate yourself in
    > code. In .net you can use the
    > "ServicePointManager.ServerCertificateValidationCallback" propertyto
    > register such a callback delegate to check the certifiate your self, e.g
    >
    > =========================
    > public static bool ValidateServerCertificate(
    > object sender,
    > X509Certificate certificate,
    > X509Chain chain,
    > SslPolicyErrors sslPolicyErrors)
    > {
    > if (sslPolicyErrors == SslPolicyErrors.None)
    > {
    > if (certificate.GetPublicKeyString() == xxxxx)
    > {
    > return true;
    > }
    > }
    >
    >
    > return false;
    > }
    > =========================
    >
    > You can refer to the following MSDN reference for detailed info:
    >
    > #ServicePointManager.ServerCertificateValidationCallback Property
    > http://msdn2.microsoft.com/en-us/library/system.net.servicepointmanager.serv
    > ercertificatevalidationcallback.aspx
    >
    >
    > #RemoteCertificateValidationCallback Delegate
    > http://msdn2.microsoft.com/en-us/library/system.net.security.remotecertifica
    > tevalidationcallback.aspx
    >
    > Please feel free to let me know if there is still anything unclear or
    > anything I missed.
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
    >
    >
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
    >
    >
    >
    John K, Oct 24, 2006
    #14
  15. Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle

    Hi John,

    X509V3 is a certificate type and this is the most poular standard used
    currently. Therefore, almost all the certificates mentioned here are of
    X509 certificate. Also, there're many different kinds of x509 certificates
    according to their usage. And SSL certificate is one of them. This
    certificate can be used to identiffy a SSL/HTTPS server which contains both
    private and public key(installed on the server). For SSL client-side, you
    can import the SSL server certificate's public certificate(only contains
    public key that can use to identify the certificate). Such public
    certificate can be get through export the server certificate on the server
    machine(no include private key).


    Windows 2000 or 2003 server has a certificate service, you can install it
    and produce different kind of test certificate that can be used in your
    local environment.

    #Use Windows Server 2003 Certificate Services Web Pages
    http://technet2.microsoft.com/WindowsServer/en/library/26453270-45e5-4ffb-9a
    25-38a661b058241033.mspx

    for more detailed information about PKI and x509 certificate ,you can also
    consult in some security specific community or forum.

    Please feel free to let me know if you have any further questions on this.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Oct 24, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Douglas Reith
    Replies:
    11
    Views:
    1,089
    Micah Cowan
    Oct 1, 2003
  2. hswerdfe
    Replies:
    1
    Views:
    723
  3. Jaap Karssenberg

    conflict between man perlipc and man perlfunc !?

    Jaap Karssenberg, Jan 9, 2004, in forum: Perl Misc
    Replies:
    0
    Views:
    155
    Jaap Karssenberg
    Jan 9, 2004
  4. A. Farber
    Replies:
    3
    Views:
    256
    Ben Morrow
    Mar 3, 2004
  5. Csaba  Gabor
    Replies:
    2
    Views:
    114
    Csaba Gabor
    May 4, 2006
Loading...

Share This Page