There is nothing inherently insecure with the concept of TLS inside TLS - and it is even done already. For example some HTTP proxies like squid support connecting to the proxy with HTTPS and then having inside this protected connection to the proxy the real connection. Also using TLS inside a VPN is a similar concept of having multiple encryption and authentication layers inside each other. As for the actual implementation one might run into problems though with a simple TLS inside TLS approach. TLS inspection proxies commonly expect a specific protocol like HTTP spoken inside the TLS - because to get to the plain data is the main point of TLS interception in the first place. If these proxies don't see the expected protocol they might simply break the connection. Thus it might be necessary to layer the inner TLS again inside the expected protocol, like layering the inner TLS inside HTTP which then gets layer inside the outer TLS. Of course after installation of my program a user could modify the trusted root store used for the inner session, by modifying the compiled program, but I think this is not a very likely scenario. Having the end user running the program as enemy is a completely different scenario than trying to pass through some untrusted proxy - i.e. endpoint vs. man in the middle. TLS inside TLS might make it a bit harder to reverse engineer and change the application, but it does not prevent it. So while it is suitable as a protection against an intercepting MITM it is not suitable as a protection against the end user.

In the given context it basically means somehow adding a backdoor to the client or server and thus getting access to the plain data before it gets encrypted or after it got decrypted. This is the common way to get around solid encryption which makes it impossible to decrypt communication sniffed by a man in the middle. There are various ways to do this, like for example compromising the application before it gets even shipped or compromising the victims system and changing the app there or even injecting there into the running process.

TL/DR: Using a public Wi-Fi is fine as long as you are making sure not to visit any site without TLS, and keep your device (particularly OS and browser) up to date. Man in the Middle Attacks An open Wi-Fi cannot compromise a properly secured TLS connection. But not every TLS connection is properly secured. The majority of the sites do not use https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security (although thankfully most major sites do), which means they are vulnerable to https://security.stackexchange.com/a/41991/235964 attacks. Most normal users, and even most tech savvy ones, will not notice it. The solution is to https://www.eff.org/deeplinks/2021/09/https-actually-everywhere in your browser. DNS is mostly also in clear, which allows anybody sniffing your traffic to intercept responses to your DNS requests and modify them. However, they will still be unable to forge a valid TLS certificate, so your browser will throw a warning. If, however, you are paranoid and want to make sure people on the open Wi-Fi cannot even see your DNS requests, you can enable DNS over HTTPS. Attacks against your Machine On a open/public Wi-Fi, an attacker can also try to attack your machine directly. For example, they can try to brute-force your password through SMB, or attempt to exploit any recent OS vulnerabilities for which you may not have a patch installed. Obviously, the solution is to keep your system up-to-date. If you're tech-savvy enough, configuring your firewall to block all unwanted incoming connections will help. (On Windows, marking a network as public will tell the OS to close several of the holes in it's firewall.) Of course, if your threat model includes zero days, you might want to stay away from public Wi-Fis altogether Note that, contrary to what some older posts on this site might imply, VPNs are not the solution to any of these problems.

You cannot just provide random command-line arguments and expect applications to do what you want them to do. That's not how programs work. Browsers explicitly include features to dump key material in order to aid in debugging. Someone wrote code that parses this specific command-line argument and implemented logic in the browser to write key material to a file. If an application isn't written to be debugged by the end-user, then you can pass random command-line arguments until the end of days and you still won't get the program to dump key material for you. But what can I do then? That depends on your skill level - in other words, there is no easy answer. Given that you fundamentally misunderstand how programs work, it's safe to assume that debugging possibly obfuscated assembler code is out of the question. You could try setting up a transparent reverse proxy and hope that the server certificate isn't hardcoded into the application. If it is, you'd likely have to use virtual patching to exchange it without the changes being permanent - but hooking into the process could trip up their anti-cheat. In simple terms: How do you dump the SSL keys? You don't.

Yes, the configuration is as follows: [client web browser] [WAF] [origin web server] So, the WAF essentially has a 'man in the middle' (MITM) position between the client web browser and the origin web server. Therefore, the scenario that you describe is entirely possible.

I don't believe there is. Though technically some firewalls/corporate proxies do sort of MITM attack and they do verify the certificates and reencrypt the traffic with their own key, so that may be similar. You can use pre-shared keys with TLS. It is specified in RFC-4279. It is hard to compare. SSL/TLS is currently the easiest, most flexible and most user friendly. It has great interoperability and so on. It also wen through large amounts of research and testing, so it can be considered more reliable than something new. On the other hand, for specific use-cases there certainly are better option. They are just not as universal. I do not know about anything outright better than TLS in all areas.

Poodle attack works on SSLv3 although there is a variant of poodle attack on TLS that appeared in recent years by accepting incorrect padding after decryption. nmap is checking the TLS/SSL version. You can find the script of poodle identification rules online. It is recommended to completely disable SSLv3 on server side. On the client side, you should always upgrade to the latest version. Also, most of the browsers/servers use "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks" to prevent any intentional downgrade of version and drop the connection.

What are the possible ways they can do that? The main ways police can obtain search records are by: Looking at local browser history on the suspect's computer (as you mentioned). Demanding connection logs from the ISP, revealing what sites have been visited. Demanding connection records from the sites that you have visited. Demanding search records from search engines, such as Google. Is it possible for ISPs to have access to that kind of information? My understanding is that anything over SSL isn't easy to decipher unless there is some kind of MITM attack. TLS encrypts web traffic, however you still need to know the IP address and domain in order to connect to a website over HTTPS, and this information is sent in the clear. When connecting to this site for example, your ISP sees the IP address of stackexchange.com, and SNI also gives away the subdomain (security). Your ISP will not know exactly what pages you viewed, however. See another question for more information on what exactly TLS protects. More specifically: https://subdomain.example.com/some/path?with=stuff | visible to ISP | encrypted | If subdomain.example.com is incriminating, then TLS will not protect you. If the rest of the URL is incriminating, then TLS will protect you from ISP snooping but will not protect you if a court order demands the connection logs from example.com. Only an anonymity network, such as Tor, can help prevent this by disassociating your real IP from the IP connecting to the websites. Does using a Tor Browser prevent these other ways? Yes, Tor Browser prevents this type of snooping because everything between you and the exit node is encrypted. The EFF has a great explanation of Tor and HTTPS. When using both, you can use this diagram to see exactly what different adversaries are able to see and from what position when you are using Tor and HTTPS together.. It is helpful to use this to develop your threat model. The diagram looks a little different if you are using Tor without HTTPS. While Tor still prevents your ISP from seeing anything other than the fact that you are using Tor, the exit node will be able to read the traffic (but it cannot tell where it came from). This can be an issue if you are submitting sensitive credentials over Tor to a website without using HTTPS. Check out the EFF link to see an interactive version of the diagram where you can toggle Tor and HTTPS status. One important thing to remember is that Tor is only a tool and, like all tools, you can use it wrong. It will not help you if you screw up and post bomb threats to your school while you are the only user of Tor at the time. Likewise, Tor does not prevent you from accidentally revealing PII.

The test program openssl s_server has several option to choose the SSL/TLS version, i.e. -ssl2, -ssl3, -tls1, -tls1_1, .... Starting with OpenSSL 1.1.0 the usage openssl s_server -help shows all actually supported options, i.e. -ssl3 is only shown if SSLv3 is actually supported. With earlier versions of OpenSSL the usage might show version which were not actually supported but an attempt to actually use these resulted in an error. Q: Is SSLv3 supported by default in OpenSSL1.1.0g? How can I know this? Since you compile it from source you can just look at the output from config: $ ./config ... Configuring OpenSSL version 1.1.0g-dev (0x10100070L) ... no-ssl3 [default] OPENSSL_NO_SSL3 Thus, it looks like SSLv3 is disabled by default.

As the image you shared indicates, this is simply the certificate used for client authentication. Basically, your device is performing an 802.1X authentication to connect to the network. This uses an EAP method to authenticate to a RADIUS server, most of the common ones establish a TLS tunnel between the client and server to protect the user credentials. When the EAP supplicant (i.e. client) begins the authentication with the RADIUS server, the server begins by providing it's certificate to the client. The client then needs to determine if it is going to send the credentials to the server. Since your device is not actually connected to the network until after you authenticate, there are only limited ways it can validate the certificate and server is valid. In the case of your OS, it is prompting you for validation that this is the server you want to send your credentials. Accepting simply allows your client to continue the authentication process. It is not installing any sort of certificate (CA or otherwise) on your device. I don’t know if this is a trusted root certification but what does this certificate enable them to do? It doesn't allow them to do anything. It allows your client to continue authenticating.

I have the feeling that you are trying to tackle the problem you have from the wrong end: I always find it a pain to create a new key for development ... I'm not sure what you are doing which causes so much pain, but if you are doing the same steps again and again it might be actually useful to find a way to automate these steps for yourself. It actually seems more secure for me as a developer than creating a self-signed certificate using publicly available tools and having the key sitting around on my hard drive for my tools to use. If anyone got that, they could spoof any website for me because I have to trust it, right? If I interpret this correctly you are creating a self-signed server certificate with basic constraints CA true (i.e. this certificate can be used to issue certificates). It is correct that this can be used to create more certificate and thus access to the certificate and its key can be used to man-in-the-middle all sites - provided that you've imported this certificate as trusted CA (certificate authority) instead of a trusted server certificate. Note that just adding an exception once the browser complains will not add this certificate as certificate authority. It also would mean that the attacker needs to have access to your system in the first place - in which case it might do even more harm. Nevertheless, this particular problem can be easily mitigated: Most (all?) browsers actually can import a self-signed server certificate which has basic constraints CA false. There are though tools which cannot deal with this and expect CA true on a self-signed certificate. One could create a CA with its own private key, let it issue some leaf certificates (basic constraints CA false) with another private key and then throw the private key of the CA away. The CA can still be imported as trusted into the browser so that all certificates issued by this CA will be trusted too. Since the private key of the CA is deleted one cannot create more certificates though. fakesite.com would send all subdomains to one page on the main website which would explain what it was for. The actual certificate and private key would be made available elsewhere such as in a github repository. It is not a good idea to use a publicly available domain for this. The problem is that it is insecure by default, i.e. the browser will resolve the domain and try to connect to it and man in the middle attacks to the domain will not be detected since everybody knows the private key to mount invisible attacks. And then the attacker could do the attacks you've already described and maybe more. Fortunately the public CA which has issued the certificate would revoke the certificate anyway if the private key gets known publicly and thus this idea would not work (provided that the browsers check for revocation - which many don't or don't do properly). But the general idea could be modified to be safer. If one simply uses a domain which will never exist publicly, a browser can only connect to the domain if the system is specifically setup for this. RFC 2606 defines some top level domains which might be used for this, i.e. .example, .test, .invalid and .localhost. When using any of these top level domains an attacker could only harm developer systems which are specifically setup to resolve such domains and which have explicitly imported this certificate as a trusted server certificate, instead of being able to harm arbitrary systems.

You should be able to add any certificates that you need to use via the ZAP Options / Certificate screen (https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsCertificate).

First of all, as it is common with TLS errors, ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome is in no way descriptive of a particular problem. Next, I admit that I have never in my life touched BitDefender and especially its TLS wiretapping techniques with a ten foot pole, nor that I'd ever wanted to. Having said that, I've seen a similar bug in similar products, so I may happen to give you a clue. See, when a TLS interceptor sees a certificate, it copies it, replaces the certificate authority data with its own and signs it, and then sends to the browser (or whatever client software is trying to make a secure request). A basic TLS interceptor doesn't do anything else to the certificate: it doesn't, say, change subject alternative name field or mangle any other X509v3 extension value. Only the CA data is changed, the rest of the certificate is left as is. As the CA data is changed, the subsequent OCSP staple won't obviously be valid, so the interceptor strips that data as well. In fact, it's acting as a proxy, so it doesn't strip anything, it just doesn't put a staple into the browser-facing connection even when it receives a staple from the server-facing connection, and that's it. Now, the browser receives the certificate, signed by the interceptor, with OCSP Must Staple on it, but doesn't get a valid OCSP staple because it's not sent by the interceptor. At this point, the best your browser is able to do is to halt the TLS connection and display a cryptic error message. NB: this is one way to break OCSP with a TLS interceptor that I'm aware of. BitDefender could be actually using another method, there are surely plenty of them.

Generally, you are using the TLS protocol, and thus initiating a handshake with the server, agreeing upon such as cipher suites and keys to use. This is a secure protocol, as long as you can trust who you are communicating with (e.g. certificate validation). You ask whether the host computer could intercept something. After the encryption has taken place, I'd say no. On a side note, the host computer is performing the encryption in an allocated area of memory. If the host is compromised to the extent that you cannot trust the memory protection of that machine, or generally the context of the process, the plaintext can be retrieved prior to encryption. But it's impossible to have zero risk, so this is not necessary something that you need to consider.

SSL Pinning is the additional layer of security implemented at the client side to let the mobile application only trust a particular SSL certificate during HTTPs connection establishment and not the certificates installed in the device trust store. Since the implementation is the client side implementation, it can be easily bypassed using the following techniques: Automated Approach Xposed modules such as SSLUnpinning 2.0. FRIDA(Dynamic Instrumentation Tool)-Universal SSL Pinning Bypass Script. Inspeckage-Android Package Inspector Manual Approach I feel this is the last, bit complex and the most reliable solution for bypassing SSL Pinning. The following are the steps to perform the same. Understand the implementation of SSL Pinning. You can refer to this Medium blog which explains the implementation of SSL Pinning using different network libraries such as OkHttp, Volley, Retrofit etc. Analyze the responsible method and map the same with the SMALI code. Once the responsible method is analyzed and identified, we can use the following approach for bypassing SSL Pinning: Tampering Application Tamper the SMALI code to bypass SSL Pinning. Re-Build the application using APKTool. Resign and install the application and capture the traffic. Reference: https://samsclass.info/android/codemod.html Runtime Hooking Once the responsible method is identified use runtime hookers such as FRIDA, JDB to hook the method and change the implementation.

Based on your question I assume that you understand how SSL interception works in general, i.e. that the SSL intercepting process (the antivirus in this case) essentially replaces the original end-to-end encrypted connection with an encrypted connection from proxy to server and with another connection from client to proxy - where the last one does not use the original server certificate but a certificate created by the proxy and issued by a proxy-specific CA trusted by the client. The question remains then how the local AV can put its proxy into the path of the traffic. One way would be to explicitly configure the proxy in the browser. A more transparent way on Windows is to use the Windows Filtering Platform (WFP) which is explicitly designed for this kind of traffic interception. To cite from Porting Packet-Processing Drivers and Apps to WFP: Windows Filtering Platform (WFP) enables TCP/IP packet filtering, inspection, and modification, connection monitoring or authorization, IPsec rules and processing, and RPC filtering ... In other words: no injection into the client is needed. Instead WFP defines a supported interface how application traffic can be intercepted and modified. Given that all traffic between an application and the remote communication peer will ultimately pass through the network stack of the OS WFP essentially provides supported hooks into this network stack and allows interception and modification without changing the application. This kind of hooks are also used by libraries like WinDivert which allow traffic interception and modification from user mode. The documentation of ESET AV also confirms that they are using WFP. To cite: Starting with Windows Vista Service Pack 1, Windows 7 and Windows Server 2008, the new Windows Filtering Platform (WFP) architecture is used to check network communication. ... There are also other ways to do similar things even before WFP was available, for example with NDIS filter drivers. And there are more ways, including injecting a DLL into the application. For some information see Comparison of User Mode and Kernel Mode Applications for Modifying HTTP Traffic.

Even though we are using a proxy, it is sufficient to check the certificate hierarchy and when it's the same inside the companys network and in my home network, I can conclude I'm not being sniffed the inputs I do You can conclude that you are not sniffed for this specific site and this specific time only. The procedure of the proxy-server to "insert" a faked https-certificate, in case there would be such a system in-place, would probably be made system-wide. That means, as I only compared the certificate-hierarchies on a few domains now, it should mean such a procedure will highly likely not be in-place at all, also not for any other domain? It is possible to intercept only selected sites or only at specific times or only specific clients (based on ClientHello fingerprint) or to explicitly not intercept some sites. Thus it is not possible to conclude from one site not being intercept that other sites will not get intercepted too or even that the same site gets not intercepted at another time or with another client. You might check if you find some unusual root certificates in your certificate store but these are not that obvious to detect. That means the only way to track my inputs, would be to use some sort of keyloggers? (Which is probably not possible / allowed by law anyhow (living in germany)). There are several ways to monitor users apart from keyloggers and HTTPS interception. For example browser plugins could be used or simply the whole system could be mirrored similar to remote desktop software. From what I gathered from the other posts here on stackexchange, they can obviously save from the logs which URLs/hostnames I have visited. They question is: Do they see the full URLs or only the hostname / the target server? Because it could potentially do a big difference whether I visited some reddit page about how to setup some software or some reddit page about po*rn Obviously I won't visit these, just from a technical POV I want to know what's possible here. Only the domain is known and not the full URL. See Are URLs viewed during HTTPS transactions to one or more websites from a single IP distinguishable?.

There are several scenarios that make it possible to intercept that connection: Your validation code is not actually validating correctly in which case another CA might sign certificates that are deemed valid by your code. Your CA's private key gets leaked, lost or otherwise compromised (for example because it gets factorized) in which case anyone in possession of the key can sign themselves a certificate that is deemed valid by your code. same thing (compromised key) for your actual certificate. Your CA might not be under your control completely (i.e. not your own CA) in which case any certificate signed by that CA (for example, any TLS certificate for any domain, if your CA is a provider of domain TLS certificates (like, for example, let's encrypt)) is deemed valid by your code. To mitigate the last possibility, you could use a self signed certificate authority that you explicitly trust in your client application, but this comes with the usual caveats of that, i.e. understanding what you're doing and keeping the CA itself safe. But how can you do that unless you have both the server's cert and the CA? Where does the private key of the server's cert factor in? This question does suggest that you are not actually understanding how a PKI or TLS works and thus that hosting your own CA might come with an increased security risk. The general idea is that the CA is not on the same machine that the certificate is deployed on - please do read up on PKI, TLS, certificate pinning and trust chains before you proceed employing your own CA.

Based on your description and the link you've provided you've likely installed a CA certificate for SSL interception. ... how do I know the certificate I have is legit? That is, actually comes from Google and not from a man in the middle? It does not come from Google. It comes from a man in the middle. It might be a legit man in the middle or not. It is usually not legit if you are using some public WLAN. It is usually legit if you are in a company which does SSL interception. But in this case ask your network administrator if you've got the correct certificate. In any case: don't just install some certificate you've got from somewhere. In case of legal SSL interception these certificates get usually automatically installed at company equipment but you might need to install it on your own equipment (if you are even allowed to use this inside the company network). But in general you should only install such a certificate after someone you trust explicitly told you that this is legal SSL interception and not just because you've got some annoying certificate warning and just want to somehow continue with what you were doing. For more details see Is it common practice for companies to MITM HTTPS traffic? and Is visiting HTTPS websites on a public hotspot secure?.

No there isn't. Your app is a guest on the system, the user is the owner of the device is the master. They get to decide what your app can or cannot do, and there isn't much you can do about it.