I am evaluating a vendor whose technology takes the following approach:

  1. My website asks user to install vendor's executable (EXE) on their machine. This EXE does operations that cannot be done in-browser
  2. EXE also starts a local web server on client's machine
  3. My website connects to 'exe.vendor-website.com'. This is a public domain, but its DNS resolves to (I'm surprised DNS providers allow this). Vendor does this because it then allows them to make HTTPS connections to the local EXE web server (via https://exe.vendor-website.com)
  4. My website talks to local EXE web server (via client-side JavaScript) to retrieve information (over REST) which therefore never leaves the client's machine. This is the primary advantage of their approach.

Note this is a public production solution, not a development-only or intranet-only solution. Vendor used to use ActiveX, but switched once ActiveX stopped being supported.

I would like to understand what security/reliability holes may exist with the vendor's design.


  1. "Why is it necessary to spoof DNS" - some browsers don't allow JavaScript to connect to http://localhost (if the site itself is not running on localhost). Marked WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=67743#c17
  2. "Did the vendor embed the private key for exe.vendor-website.com in their executable" - yes, they implied this
  • "it then allows them to make HTTPS connections to the local EXE web server" This seems to be the whole point of this scheme. Why is this necessary though? Nov 26, 2020 at 2:07
  • 1
    Did the vendor embed the private key for exe.vendor-website.com in their executable, where anyone can easily extract it? Nov 26, 2020 at 2:08
  • @JosephSible-ReinstateMonica My guess is that otherwise you could use WireShark/similar to eavesdrop the contents of communication between client-side JavaScript and local web server. I don't know if you can run WireShark for connections though? Nov 26, 2020 at 2:09
  • Who is the "you" that could use Wireshark? By default, only local admins can, and local admins can steal locally encrypted data too, by reading it out of RAM. Nov 26, 2020 at 2:09
  • Yes, vendor implied private key was embedded in executable, though said it was encrypted in a keystore Nov 26, 2020 at 2:10

1 Answer 1


The vendor is shipping their private key to all of their customers, on purpose. Even if this shouldn't really matter since it's only used to encrypt traffic going over localhost, it demonstrates a severe lack of security knowledge on the vendor's part. My advice: avoid like the plague.

  • Could you theorize any attacks that could be made based on this? Nov 26, 2020 at 2:22
  • 2
    If someone extracts the private key from the executable, they can request prompt revocation from the CA as the key was compromised. Until the vendor gets another certificate (provided they can get one) and updates the executable, some browsers will block all requests to the service. They then have a few days until the new key is extracted and the certificate revoked, and you're back to a non-functional service. Dec 26, 2020 at 9:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .