You can't download the private part of the TLS certificate by pretending to be a browser. You can't publicly download it at all. Your browser comes with a chain of public certificates from reputable CA vendors, and you verify that a site is who it claims to be by using their public certificate (which your browser downloads).

The only way they can succeed in proving who they are, is if their server has access to the corresponding private key of the certificate, which is why you can't spoof a properly secured site unless you either hack their server, crack the encryption, or install your phony certificate on the client (which is what corporations sometimes mandate). That's it.

It's been 17 years since 2000. Whatever security hole you may have used (if any) has long since been patched. The weak cyphers used in some SSL versions which you may have depended on are mostly gone (certainly from high profile targets).

If what you state is true, now in 2017, then there would have to be a huge conspiracy which involves all browser vendors (including Mozilla), as well as all national governments and the EU that hides this fact from the people. All software developers who do catch on (the relevant source code is open source after all) would have to bribed or threatened into silence too.

You are either misinformed or consciously spreading misinformation.

> It's been 17 years since 2000. Whatever security hole you may have used (if any) has long since been patched. The weak cyphers used in some SSL versions which you may have depended on are mostly gone (certainly from high profile targets).

I very much doubt he was even doing anything that clever. Since it was a corporate network he probably just had their corporate CA certificate already built as part of the company machine images / build scripts. He possibly might not even have been aware this was happening if the IT department was large enough that different coworkers managed the desktops from himself.

The "I can't disclose much" argument on a 2 decade old hack is effectively just saying "I can't remember the details" or "I wasn't directly involved in setting up the proxy". Either way, while much has changed in the last 17 years, the practice of some businesses installing their own CA certificates on company assets has been a fairly standard way for corporate proxies to intercept HTTPS traffic. And a great deal less trouble than relying on SSL vulnerabilities since you already own and deploy the destination hardware+software anyway.

Anyone can easily find me on the net and I don't need to have fun speaking with lawyers.

Believe me or not, I don't care.

I don't really understand what lawyers have to do with the discussion but I certainly do believe you that you had an in-house proxy that did MITM HTTPS traffic. Lots of businesses do. The problem is you said "let me tell you it is quite easy to MITM by any company owning part of the connection" using that as your example. While your anecdote may be true, the statement it is trying to support simply isn't true and neither was your description of how SSL works (eg the proxy server being able to disable the client libraries SSL checks).

So it's not that I don't believe your anecdote - I'm sure that did happen in some form or other - but the nature of the exploit either isn't how you described or is so old and long since patched that it hasn't been exploitable in more than a decade thus isn't relevant to the statement you were trying to support.

You're loosely describing the 2nd attack I mentioned but overlooking the issue of the SSL handshake. You cannot perform your attack without having the server's private key, which as name suggests, is privately stored on the remote TLS endpoint. The private key is used to confirm that the client has received the websites certificates without getting MITMed. Since you don't have the websites private key you cannot use their public key in the way you described.

The workaround for that is to create your own SSL certificate for that website (this will create you a public certificate and private key). Which means you will also need that new certificate CA signed otherwise the client (who's own SSL validations you cannot remotely disable like you implied) will give the user a warning about an untrusted certificate (the message will vary from client to client). This means you either need access to the targeted client to install your own CA certs, or you need access to a compromised signing authority.

They are not. Either I get content as the key'ed server sent it, or I do not. MITM of a https source under the same domain is not possible (caveate is manually accepting a new certificate in my local browser).