none
How to validate server's certificate during HTTPS negotiation RRS feed

  • Question

  • I understood HTTPS is like HTTP, a built-in APP(protocol handler) supported in IE web browser control.

    When creating a HTML application using web browser control for loading web content from internet, I want the app to verify some fields presented in server certificate which the app trying to communicate during the handshake negotiation.
    Is there any way I can achieve this with known web browser control interfaces, methods or override HTTPS APP somewhat, or register a callback for custom actions like ServerCertificateValidationCallback in managed code?

    Any helpful info and feedback are greatly appreciated. Thanks in advance.

    Monday, November 5, 2012 11:44 PM

Answers

  • On 11/5/2012 6:44 PM, Mr_Jones_ wrote:

    I understood _HTTPS_ is like/_HTTP_/, a built-in /_APP_/(protocol handler) supported in IE web browser control.

    When creating a HTML application using web browser control for loading web content from internet, I want the app to verify some fields presented in server certificate which the app trying to communicate during the handshake negotiation.

    Certificates are handled automatically by WinInet, which is a layer underneath APP. I don't know of any way to dig CERT_CONTEXT out of WinInet. The best you can have is INTERNET_CERTIFICATE_INFO, which doesn't really contain much useful information. But if you want it, call IWinInetInfo::QueryOption(INTERNET_OPTION_SECURITY_CERTIFICATE_STRUCT).


    Igor Tandetnik

    Monday, November 5, 2012 11:53 PM
  • Mr_Jones_ wrote:

    Thanks Igor for quick reply.

    INTERNET_CERTIFICATE_INFO has sufficient info for common fields  inspection.

    How do I code to retrieveINTERNET_CERTIFICATE_INFO, ideally during  HTTPS negotiation, or just before HTML form submission.

    You would need something like (shameless plug alert) my Passthough APP.  See long discussion here, with further links:

    http://social.msdn.microsoft.com/Forums/en/ieextensiondevelopment/thread/ a7ab3ecc-633c-4a9a-8290-bd6f34c41ada

    It's pretty complicated, not for the faint of heart.

    There's also this:

    http://www.codeproject.com/Articles/18935/The-most-complete-C-Webbrowser- wrapper-control

    Apparently, it uses some version of my code, wrapped in a way to make it  usable from C#. I haven't used it myself and haven't looked at it in any  detail.

    Whatever the mechanism you end up using, the idea is to intercept  IHttpNegotiate::OnResponse call, query the real APP for IWinInetInfo,  and call QueryOption(INTERNET_OPTION_SECURITY_CERTIFICATE_STRUCT).

    If you don't mind me asking - what's the ultimate goal of the exercise?  You do realize that WinInet already verifies the validity of the server  certificate, right? Meaning that the certificate is trusted, and that  it's issued for the same domain name the request is issued to.


    Igor Tandetnik

    Tuesday, November 6, 2012 1:51 AM

All replies

  • On 11/5/2012 6:44 PM, Mr_Jones_ wrote:

    I understood _HTTPS_ is like/_HTTP_/, a built-in /_APP_/(protocol handler) supported in IE web browser control.

    When creating a HTML application using web browser control for loading web content from internet, I want the app to verify some fields presented in server certificate which the app trying to communicate during the handshake negotiation.

    Certificates are handled automatically by WinInet, which is a layer underneath APP. I don't know of any way to dig CERT_CONTEXT out of WinInet. The best you can have is INTERNET_CERTIFICATE_INFO, which doesn't really contain much useful information. But if you want it, call IWinInetInfo::QueryOption(INTERNET_OPTION_SECURITY_CERTIFICATE_STRUCT).


    Igor Tandetnik

    Monday, November 5, 2012 11:53 PM
  • Thanks Igor for quick reply.

    INTERNET_CERTIFICATE_INFO has sufficient info for common fields inspection.

    How do I code to retrieve INTERNET_CERTIFICATE_INFO, ideally during HTTPS negotiation, or just before HTML form submission.

    Would you please throw more instructions or sample code? I am a newbie to IE extension, Appreciated!

    Tuesday, November 6, 2012 12:46 AM
  • Mr_Jones_ wrote:

    Thanks Igor for quick reply.

    INTERNET_CERTIFICATE_INFO has sufficient info for common fields  inspection.

    How do I code to retrieveINTERNET_CERTIFICATE_INFO, ideally during  HTTPS negotiation, or just before HTML form submission.

    You would need something like (shameless plug alert) my Passthough APP.  See long discussion here, with further links:

    http://social.msdn.microsoft.com/Forums/en/ieextensiondevelopment/thread/ a7ab3ecc-633c-4a9a-8290-bd6f34c41ada

    It's pretty complicated, not for the faint of heart.

    There's also this:

    http://www.codeproject.com/Articles/18935/The-most-complete-C-Webbrowser- wrapper-control

    Apparently, it uses some version of my code, wrapped in a way to make it  usable from C#. I haven't used it myself and haven't looked at it in any  detail.

    Whatever the mechanism you end up using, the idea is to intercept  IHttpNegotiate::OnResponse call, query the real APP for IWinInetInfo,  and call QueryOption(INTERNET_OPTION_SECURITY_CERTIFICATE_STRUCT).

    If you don't mind me asking - what's the ultimate goal of the exercise?  You do realize that WinInet already verifies the validity of the server  certificate, right? Meaning that the certificate is trusted, and that  it's issued for the same domain name the request is issued to.


    Igor Tandetnik

    Tuesday, November 6, 2012 1:51 AM
  • Thanks for detailed info, appreciate that!

    My motivation behind the scene: the IE only use Authenticode to validate certificate signed by one of the CA which listed in certificate store(and other stuff like integrity of data, timestamp, CRL etc.).
    The need for validating for example, the subject name against trusted domain, can further prove whether client is talking to deemed trusted server, not any other malicious nodes(i.e. ManInTheMiddle attack).

    I was even thinking about this idea if it cannot be done in IWebBrowser2 code, when intercept and stop on form submission event, I do a quick sanity check to server certificate in a separated request using WinHTTP or WinINet, where I can retrieve certificate info for validation needs. Then determine whether proceed with submission or drop it. 

    I was intimidated when you say 'pretty complicated' :<.....

    I'll check Passthough APP, if have any question please don't mind I buzz you again.

    Tuesday, November 6, 2012 4:34 AM
  • Mr_Jones_ wrote:

    My motivation behind the scene: the IE only use Authenticode to  validate certificate

    Authenticode is a technology for signing ActiveX controls. It has  nothing whatsoever to do with HTTPS.

    signed by one of the CA which listed in
    certificate store(and other stuff like integrity of data, timestamp,  CRL etc.). The need for validating for example, the subject name against trusted  domain

    WinInet verifies that the subject name on the cerificate matches the  domain name in the URL. It's the whole point of the exercise. HTTPS  would be completely useless otherwise.

    I'm not sure what you mean by "trusted domain". If you only want  requests sent to certain domains, just handle BeforeNavigate2 event from  WebBrowser control, check that the domain in the URL is to your liking,  cancel the request otherwise.


    Igor Tandetnik

    Tuesday, November 6, 2012 5:06 AM
  • Igor,

    I don't think certificate has domain name for WinINet to check, 'subject name' often refers to 'entity name', eg. "Microsoft Corp."

    Try to setup a proxy like Fiddler, see if you can intercept traffic for https://www.google.com.

    Tuesday, November 6, 2012 3:39 PM
  • On 11/6/2012 10:39 AM, Mr_Jones_ wrote:

    I don't think certificate has domain name for WinINet to check

    Does too, of course. That's what makes SSL work.

    'subject name' often refers to 'entity name', eg. "Microsoft Corp."

    I just navigated to https://www.microsoft.com and looked at the certificate. Subject: CN = www.microsoft.com. Also, many certificates come with Subject Alternative Name (SAN) extension - this allows a single certificate to be good for several domain names (usually, owned by the same organization).

    Try to setup a proxy like Fiddler, see if you can intercept traffic for https://www.google.com.

    I'm not sure I understand this comment. What exactly are you trying to prove?


    Igor Tandetnik

    Tuesday, November 6, 2012 4:52 PM
  • He want prove that you can construct same certificate from own certificate authority and place it in fake web application add this certificate or  authority certificate  to client trusted authorities add put own dns resolving mechanism that will force client to use your web app. Then you will get all client information e.g. passwords to bank account. If you are developer and want have sure client is using your web app not any fake one you must verify certificate e.g. checking if thumbprint of cert is correct.
    Monday, March 18, 2019 7:51 AM