Decrypt SSL?

[tvhawaii 2]

I'm ignorant when it comes to ssh/ssl. Is this webcast saying that these packets are viewable as plain text?

Thank you

~~~~~~~~~~~~~~~~~~~~~~~

Webcast Overview:

Blind as a Bat? Or Eagle Vision Into Encrypted Packets?

Featuring: Dave Shackleford and Tony Zirnoon

Bad actors now commonly hide payloads, bot commands and outbound sensitive data behind SSL, which network monitoring tools are blind to. While there are tools to decrypt packets, users have problems setting them up to operate real-time and inline due to performance issues and limitations within individual brands of products.

In this webcast, learn the pros and cons of today's network packet decryption solutions and how to mitigate stress points with optimized network monitoring. By using a packet broker model, organizations can achieve:

Real-time inline monitoring for sensitive data leakage and commands hidden behind SSL encrypted traffic

Load balancing by offloading of suspicious traffic to selectable devices so decryption won't impact traffic speeds

Agnosticism: A broker can send decrypted packets to any type or brand of monitoring/intrusion device

Real-time reporting and analysis of the decrypted traffic and reports

Register for this webcast and be among the first to receive a link to the associated whitepaper developed by senior SANS Analyst, Dave Shackleford.

https://www.sans.org/webcasts/blind-bat-eagle-vision-encrypted-packets-95662

[tvhawaii 2]

Can my ISP get one of these boxes and look at my traffic in clear text?

http://www.vssmonitoring.com/products/vInspector.asp

Checkout their list of customers and Gov't organizations that have them!

If so, what's the point of AirVPN? What am I missing? Admin, Please.

Thanks

[Staff 9773]

Can my ISP get one of these boxes and look at my traffic in clear text?

http://www.vssmonitoring.com/products/vInspector.asp

Checkout their list of customers and Gov't organizations that have them!

If so, what's the point of AirVPN? What am I missing? Admin, Please.

Thanks

Hello!

It's not possible to decrypt the packets you send to the VPN server and the packets you receive from the VPN server (not even by someone who's monitoring your line), except by your client. The device you link is meant to decrypt and re-encrypt SSL traffic for which it has already all the keys. This can be obtained in corporate environments or with malicious means, to which an OpenVPN hardened security based VPN is not vulnerable. To have a closer hint on how these devices work:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65123

EDIT

If you're curious to see the strength of AES (Air data channel is encrypted with AES-256-CBC):

http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks

The fastest known attack against AES-256 requires 2^254 operations for key discovery... and OpenVPN executes TLS re-keying every 60 minutes.

Kind regards

[Anonymous Writer 2]

Can my ISP get one of these boxes and look at my traffic in clear text?

http://www.vssmonitoring.com/products/vInspector.asp

Checkout their list of customers and Gov't organizations that have them!

If so, what's the point of AirVPN? What am I missing? Admin, Please.

Thanks

The link does not work. And I strongly suspect this is rubbish to the nth power. The traffic is encrypted and cannot be parsed in plain text. I have never heard or read of anything bypassing strong encryption. This is fanciful nonsense.

[Staff 9773]

Can my ISP get one of these boxes and look at my traffic in clear text?

http://www.vssmonitoring.com/products/vInspector.asp

Checkout their list of customers and Gov't organizations that have them!

If so, what's the point of AirVPN? What am I missing? Admin, Please.

Thanks

The link does not work. And I strongly suspect this is rubbish to the nth power. The traffic is encrypted and cannot be parsed in plain text. I have never heard or read of anything bypassing strong encryption. This is fanciful nonsense.

Hello!

You can imagine a situation where a citizen is "locked in a cage": the adversary must have the ability to poison the victim DNS and propose alternative (or stolen) SSL certificates which "look like" the original site. The victim is led to believe that he/she is not in a such a "caged" network and that the certificates he/she receives from the https websites are not fake.

With the device advertised in the tvhawaii's link, the adversary can more easily succeed in its attack, because the device acts as a gateway to the real https website and sends fluidly (quickly enough so that the victim can't notice any suspect lag) the real pages of the site the victim connects to. Each vInspector devices is advertised as capable to handle up to 3.5 Gbit/s SSL throughput. Actually, this admin has had direct experience that this method has been repeatedly used by human rights hostile governments in order to capture and "decrypt" the traffic of their citizens to/from https websites, including GMail and Facebook.

Kind regards

[tvhawaii 2]

Thank you for your prompt and informative reply.

I'll renew for another year.<grin>

[Anonymous Writer 2]

Can my ISP get one of these boxes and look at my traffic in clear text?

http://www.vssmonitoring.com/products/vInspector.asp

Checkout their list of customers and Gov't organizations that have them!

If so, what's the point of AirVPN? What am I missing? Admin, Please.

Thanks

The link does not work. And I strongly suspect this is rubbish to the nth power. The traffic is encrypted and cannot be parsed in plain text. I have never heard or read of anything bypassing strong encryption. This is fanciful nonsense.

Hello!

You can imagine a situation where a citizen is "locked in a cage": the adversary must have the ability to poison the victim DNS and propose alternative (or stolen) SSL certificates which "look like" the original site. The victim is led to believe that he/she is not in a such a "caged" network and that the certificates he/she receives from the https websites are not fake.

With the device advertised in the tvhawaii's link, the adversary can more easily succeed in its attack, because the device acts as a gateway to the real https website and sends fluidly (quickly enough so that the victim can't notice any suspect lag) the real pages of the site the victim connects to. Each vInspector devices is advertised as capable to handle up to 3.5 Gbit/s SSL throughput. Actually, this admin has had direct experience that this method has been repeatedly used by human rights hostile governments in order to capture and "decrypt" the traffic of their citizens to/from https websites, including GMail and Facebook.

Kind regards

I followed the link from https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5149&limit=6&limitstart=12&Itemid=142 to see the evidence and I cannot see it.

As for the argument above, this is an entirely different animal altogether and can apply to any service or website. This is not applicable only to Tor and never has been. The original poster never meant his words to mean what you wrote above. The ISP cannot sniff the traffic under normal circumstances. No one disputes the ability of a strong opponent to do what you describe above but this goes beyond decrypting encrypted data. I fail to see the connection to Tor alone.

Thank you

[Staff 9773]

Can my ISP get one of these boxes and look at my traffic in clear text?

http://www.vssmonitoring.com/products/vInspector.asp

Checkout their list of customers and Gov't organizations that have them!

If so, what's the point of AirVPN? What am I missing? Admin, Please.

Thanks

The link does not work. And I strongly suspect this is rubbish to the nth power. The traffic is encrypted and cannot be parsed in plain text. I have never heard or read of anything bypassing strong encryption. This is fanciful nonsense.

Hello!

You can imagine a situation where a citizen is "locked in a cage": the adversary must have the ability to poison the victim DNS and propose alternative (or stolen) SSL certificates which "look like" the original site. The victim is led to believe that he/she is not in a such a "caged" network and that the certificates he/she receives from the https websites are not fake.

With the device advertised in the tvhawaii's link, the adversary can more easily succeed in its attack, because the device acts as a gateway to the real https website and sends fluidly (quickly enough so that the victim can't notice any suspect lag) the real pages of the site the victim connects to. Each vInspector devices is advertised as capable to handle up to 3.5 Gbit/s SSL throughput. Actually, this admin has had direct experience that this method has been repeatedly used by human rights hostile governments in order to capture and "decrypt" the traffic of their citizens to/from https websites, including GMail and Facebook.

Kind regards

I followed the link from https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5149&limit=6&limitstart=12&Itemid=142 to see the evidence and I cannot see it.

As for the argument above, this is an entirely different animal altogether and can apply to any service or website. This is not applicable only to Tor and never has been. The original poster never meant his words to mean what you wrote above. The ISP cannot sniff the traffic under normal circumstances. No one disputes the ability of a strong opponent to do what you describe above but this goes beyond decrypting encrypted data. I fail to see the connection to Tor alone.

Thank you

Hello!

About the link provided by tvhawaii, it works, please check it out.

About the required evidence on how it has been possible to successfully attack a target and decrypt the victim's traffic even with https-only websites, it is this admin's direct experience. Some of these events (but not all) have been anyway widely documented, for example:

http://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail

In these types of attacks, the device advertised in the link provided by tvhawaii is indeed useful and can help the attacker, because the attacker obviously does not want to reproduce the victim website in its entirety, but does want that the victim connects finally to the real website without getting warnings from his/her browser.

Assuming that the victim does not have from a trusted source the SH1 and MD5 certificate fingerprints and/or does not check manually them (the manual check is necessary because the browser will not issue any warning, being the certificate "trusted" for the browser), the attacker has been able to decrypt all the victim's https traffic to and from https websites while the victim was believing that his/her traffic was securely encrypted. Using vInspector or similar products is an additional comfort for the attacker and adds some more "nice" options, such as real time de-cryption and re-encryption of the https website pages accessed by the victims, de-cryption and re-encryption of the data the victims send to those sites, injections on the fly.

Wikipedia has a short but nice article about the huge problem with SSL certificates emitted by CA authorities, their intrinsic weaknesses, some examples on how to perform a successful attack and some more references to notable attacks in the past which were successful:

http://en.wikipedia.org/wiki/Certificate_authority

The vulnerabilities can be greatly mitigated with OpenVPN, because once the connection is established toward servers which present certificates not subjected to subversion, the attack basis is no more available to the attacker. Therefore the attacker must face the new problem to hi-jack the victim without having the victim in the cage anymore.

While this cage might still work with TOR (working in the cage so that a circuit either can not be established or it has high probability to be established only with relays and exit nodes controlled by the attacker), a VPN with non public entry-IP addresses is much more difficult to block.

Currently the only solution to the attacker (as far as we know, of course) is just to disrupt OpenVPN connections completely (without disrupting SSL/TLS connections, because the attacker wishes that the victim remains able to connect to https websites), which can be achieved for the typical fingerprint of OpenVPN handshake, which is uniquely recognizable with DPI (we are working to try to bypass this limitation because this method is currently applied at least in Syria, Iran and intermittently in vast areas of China).

About the "normal circumstances" you cite, it would help that you define what these normal circumstances are, and anyway it can be a dangerous mistake to assume that such circumstances surely apply to tvhawaii or any other person.

Kind regards

[Anonymous Writer 2]

Hello!

About the link provided by tvhawaii, it works, please check it out.[/quote

Yes, it works now; it did not earlier.

Thank you.

About the required evidence on how it has been possible to successfully attack a target and decrypt the victim's traffic even with https-only websites, it is this admin's direct experience. Some of these events (but not all) have been anyway widely documented, for example:

www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail

This is starting to remind me of Plato's dialogues (Socratic dialogue) when Socrates' opponents keep changing the original argument and redefining them as the conversation goes on. The “About the required evidence on how it has been possible to successfully attack a target and decrypt the victim's traffic even with https-only websites” you write of is about the security of independent websites with independent SSL certificates; it is not, however, about the original discussion—namely the safety and security of the Tor service.

In these types of attacks, the device advertised in the link provided by tvhawaii is indeed useful and can help the attacker, because the attacker obviously does not want to reproduce the victim website in its entirety, but does want that the victim connects finally to the real website without getting warnings from his/her browser.

The link of the original poster made no such statements. According to the website:

The vInspector™ Series provides real-time and bi-directional decryption and re-encryption of SSL traffic flowing across enterprise networks. This makes it possible for your security tools to identify threats hidden in SSL encrypted traffic. Its exceptional performance, scale and efficiency allows you to decrypt SSL traffic once, and give clear-text visibility to many tools.

The original author assumed, erroneously, that this device can decrypt traffic, which it can—but not traffic belonging to a different network or a different service—only a particular network. In other words, if I am using Tor, an ISP using this device cannot decrypt the traffic, since the ISP does not possess the decryption keys of Tor. It can only decrypt the traffic it has a key to. This device is for network security, to prevent hacking and to safeguard the network. It is not for governments or ISPs or hackers to decrypt traffic. More about this below.

Assuming that the victim does not have from a trusted source the SH1 and MD5 certificate fingerprints and/or does not check manually them (the manual check is necessary because the browser will not issue any warning, being the certificate "trusted" for the browser), the attacker has been able to decrypt all the victim's https traffic to and from https websites while the victim was believing that his/her traffic was securely encrypted. Using vInspector or similar products is an additional comfort for the attacker and adds some more "nice" options, such as real time de-cryption and re-encryption of the https website pages accessed by the victims, de-cryption and re-encryption of the data the victims send to those sites, injections on the fly.

Even if the the device can be used to decrypt network traffic of a fraudulent or compromised certificate, it still has nothing to do with the original argument.

Wikipedia has a short but nice article about the huge problem with SSL certificates emitted by CA authorities, their intrinsic weaknesses, some examples on how to perform a successful attack and some more references to notable attacks in the past which were successful:

en.wikipedia.org/wiki/Certificate_authority

No one disputes the potential dangers of fraudulent or hacked SSL certificates. And, no one questions that a lot of SSL certificates on the Internet have potential security issues. This is why there are services such as the SSL Observatory https://www.eff.org/observatory/.

The vulnerabilities can be greatly mitigated with OpenVPN, because once the connection is established toward servers which present certificates not subjected to subversion, the attack basis is no more available to the attacker. Therefore the attacker must face the new problem to hi-jack the victim without having the victim in the cage anymore.

While this cage might still work with TOR (working in the cage so that a circuit either can not be established or it has high probability to be established only with relays and exit nodes controlled by the attacker), a VPN with non public entry-IP addresses is much more difficult to block.

This is where you make serious errors. The original argument:

Tor exit nodes can be good or bad.

Tor exit nodes can be used to sniff data traffic (all HTTP traffic can be sniffed in transit or by the operator regardless of the service, including a VPN).

Tor exit nodes cannot be used to sniff encrypted websites. Notice the keywords “exit nodes.”

You have provided no evidence to the contrary.

Instead, you changed the original argument and you are now suggesting that if fraudulent SSL certificates are used, the traffic can be decrypted with the vInspector. Now no one disputes that if the SSL certificate is fraudulent, that the encrypted traffic submitted can be sniffed by hackers. But this is not the original argument.

Moreover, the argument that a VPN will protect you more than Tor in this respect is illogical. If someone logs into online banking, which has a fraudulent SSL certificate, whether by Tor or a VPN, it makes no difference; the traffic will be sniffed. Once the traffic is delivered to the website, it is vulnerable.

In other words, this is not the fault of a Tor exit node or the VPN; rather, it is the fault of a third party service (website) which has had its security breached. But our original discussion is about the security of the Tor service, not the security of independent SSL certificates.

If you are making the accusation that the Tor service and its network is insecure, because of fraudulent or compromised SSL certificates, then you need actual evidence to prove this. You cannot make general statements that SSL certificates can be compromised or issued fraudulently and that this could be used to decrypt Tor exit node traffic to compromised HTTPS websites but miraculously protect OpenVPN traffic.

About the "normal circumstances" you cite, it would help that you define what these normal circumstances are, and anyway it can be a dangerous mistake to assume that such circumstances surely apply to tvhawaii or any other person.

By “normal,” I am here referring to Tor exit nodes (as in the original discussion, before you changed the definitions and the argument) and that data transmitted from Tor exit nodes is safe for encrypted websites, since the encryption of the third party website is independent of the Tor service and is assumed to be secure. And even if “a” third party website certificate is not secure, then neither a VPN service nor Tor will protect you when connecting to this compromised website.

All exit traffic from a VPN and Tor is transmitted decrypted to a website. If the website is encrypted, then the traffic transmitted from a VPN or Tor is encrypted. If website security has been breached, then all traffic, regardless of whether it is a VPN or not, will be sniffed.

All HTTP traffic, whether a VPN or Tor, can be sniffed in transit.

So once again, your argument is incorrect.

Thank you

[Staff 9773]

This is starting to remind me of Plato's dialogues (Socratic dialogue) when Socrates' opponents keep changing the original argument and redefining them as the conversation goes on.[...] it is not, however, about the original discussion—namely the safety and security of the Tor service. [...] Instead, you changed the original argument [...] But this is not the original argument.

Hello!

You have confused two different threads, you're mixing up this one with "What's the point of VPN over TOR?".

Kind regards

[Staff 9773]

This is where you make serious errors. The original argument:

Tor exit nodes can be good or bad.

Tor exit nodes can be used to sniff data traffic (all HTTP traffic can be sniffed in transit or by the operator regardless of the service, including a VPN).

Tor exit nodes cannot be used to sniff encrypted websites. Notice the keywords “exit nodes.”

You have provided no evidence to the contrary.

Hello!

Please re-read, you have been given all the elements on how such attacks have the chance to be successful. In particular, to achieve the scope the adversary, in addition to regularly signed certificates, needs to block TOR or increase significantly the probability that the circuit is established with nodes controlled by the attacker (see the previous message for more details).

Moreover, the argument that a VPN will protect you more than Tor in this respect is illogical. If someone logs into online banking, which has a fraudulent SSL certificate, whether by Tor or a VPN, it makes no difference; the traffic will be sniffed. Once the traffic is delivered to the website, it is vulnerable.

The purpose of the previously mentioned attacks are the opposite, that is intercepting the traffic to the real website: the hi-jacking may be only at the login page, which may be absolutely necessary in order to allow (only if needed) the correct "interfacing" with the victim toward the real website. After that all the victim traffic comes and goes to the real website. On the victim side, the outgoing traffic is encrypted with the keys already known by the interface, which decrypts the victim traffic, re-encrypts it and sends it to the real website. On the victim inbound flow, the interface decrypts the traffic from the real website (in this phase, if it is wished, packet injections/packet forging are performed) re-encrypts it with the previous keys and sends it to the victim. It is a very similar thing which can be performed in corporate environments to check the payload of https traffic, for which vInspector has been designed, with the difference that in corporate environments certificates don't need to be properly signed or stolen.

Also (this is just out of curiosity), it is similar to what currently performed by some malicious TOR relays. Currently there are:

- 1 known exit node which performs MITM of SSL attack;

- 1 known exit node which performs MITM of SSL attack with self-signed certificate;

- 1 known exit node which performs MITM of SSL attack with a Fortinet certificate;

- 1 known exit node which performs MITM of SSL attack with Kaspersky AV antivirus certificates

https://trac.torproject.org/projects/tor/wiki/doc/badRelays

In other words, this is not the fault of a Tor exit node or the VPN; rather, it is the fault of a third party service (website) which has had its security breached.

Absolutely not, this is not a fault of the original website (for example Google), which suffered no security breach. In the example the security breach was in a CA website, but in the given links (for example in the Wikipedia article and in its references) you can see how it is possible to do that without even breaching the security of the sites of an authority.

Aobut all the rest, you are confusing two different threads so you are making assumptions on what admin wrote which are not true.

Kind regards

[Anonymous Writer 2]

This is starting to remind me of Plato's dialogues (Socratic dialogue) when Socrates' opponents keep changing the original argument and redefining them as the conversation goes on.[...] it is not, however, about the original discussion—namely the safety and security of the Tor service. [...] Instead, you changed the original argument [...] But this is not the original argument.

Hello!

You have confused two different threads, you're mixing up this one with "What's the point of VPN over TOR?".

Kind regards

We both know that is not true. I came to this thread because you gave a link to this thread from the VPN over Tor thread on the grounds that you had evidence showing that Tor is insecure. I came to this thread to find this evidence. I found no such evidence, except a new argument based on new assumptions.

[Anonymous Writer 2]

Hello!

Please re-read, you have been given all the elements on how such attacks have the chance to be successful. In particular, to achieve the scope the adversary, in addition to regularly signed certificates, needs to block TOR or increase significantly the probability that the circuit is established with nodes controlled by the attacker (see the previous message for more details).

You seem to not understand. Even if a website's SSL certificate is compromised, a VPN will not protect you. The data will be sniffed. So this argument is not against Tor alone, but all services. Are you actually arguing that using an OpenVPN will protect you from this type of attack? Are you joking?

Second, as for blocking Tor, so what? What does this accomplish?

Third, as for an attacker gaining control of the network to such an extent and to manipulate it and then compromise a website's SSL certificate or to forge it, in the hope that some nameless anonymous individual's login credentials are sniffed is so far out in left field it is a joke.

Do you remember the link you gave in the other thread that “proved” you argument, when in fact it did the opposite, do you remember what the original poster stated? Virtually no one used Tor for sensitive content—all sniffed data was on port 80.

(1) Few use Tor for login credentials (except perhaps anonymous encrypted email).

(2). Even if someone did use Tor to login to their bank, their credit card, or a government website, to suggest that some hacker or hackers are going to take over HSBC, whilst at the same time procure a strong hold of the Tor network, all in the hopes of catching one or two people logging into HSBC via Tor is probably the most illogical thing you have uttered thus far.

Your whole argument rests on a lot of “ifs” and a lot of “assumptions”--all in all, I doubt anyone reading these threads will think any of your statements exhibit any logic.

The fact remains—this whole argument applies to all services, including the AirVPN. The only difference is that supposedly, the attacker gained control of the Tor network, but of course the VPN operator, who can not be tempted to sniff data traffic like the Tor exit node operator, is exempt. Why? Cannot the VPN operator, in addition to operating a server, also hack a website, so when people exit out of a single hop service, the data will be decrypted by the operator and/or his friends?

What is the difference? The difference is that with a single hop VPN service, the operator can see every one's IP address and see exactly where the traffic goes. And thus, he can more easily decide to hack any popular website and sniff all data to that encrypted website.

The purpose of the previously mentioned attacks are the opposite, that is intercepting the traffic to the real website: the hi-jacking may be only at the login page, which may be absolutely necessary in order to allow (only if needed) the correct "interfacing" with the victim toward the real website. After that all the victim traffic comes and goes to the real website. On the victim side, the outgoing traffic is encrypted with the keys already known by the interface, which decrypts the victim traffic, re-encrypts it and sends it to the real website. On the victim inbound flow, the interface decrypts the traffic from the real website (in this phase, if it is wished, packet injections/packet forging are performed) re-encrypts it with the previous keys and sends it to the victim. It is a very similar thing which can be performed in corporate environments to check the payload of https traffic, for which vInspector has been designed, with the difference that in corporate environments certificates don't need to be properly signed or stolen.

I think you are sorely confounding many different things.

Absolutely not, this is not a fault of the original website (for example Google), which suffered no security breach. In the example the security breach was in a CA website, but in the given links (for example in the Wikipedia article and in its references) you can see how it is possible to do that without even breaching the security of the sites of an authority.

Yes, I am aware of that. I was not making specific references to any particular hack. The argument was that the breach was on a third party site; it was not the Tor service. Whether the third party site is CA website or Google, it matters little.

Aobut all the rest, you are confusing two different threads so you are making assumptions on what admin wrote which are not true.

Not so. I followed your link to this thread in the hope of evidence. Instead, I received a new argument that has nothing to do with the original discussion.

[Staff 9773]

If you are making the accusation that the Tor service and its network is insecure, because of fraudulent or compromised SSL certificates, then you need actual evidence to prove this. You cannot make general statements that SSL certificates can be compromised or issued fraudulently and that this could be used to decrypt Tor exit node traffic to compromised HTTPS websites but miraculously protect OpenVPN traffic.

Hello!

As shown, there are currently various known TOR exit nodes which perform exactly that.

In the previous scenario, as it was clearly stated, the attacker was able both to control the significant portion of the TOR network and had valid SSL certificates, regularly signed. In this way using AirVPN can defeat the attacker, simply because the attacker has full control of the border routers, the ISPs in its country and runs a significant number of the only TOR exit nodes (if any) available for establishing a circuit, but not of the networks out of its country. Actually, currently the only way for the attacker to solve this "problem" is only disrupting completely OpenVPN connections.

About the "normal circumstances" you cite, it would help that you define what these normal circumstances are, and anyway it can be a dangerous mistake to assume that such circumstances surely apply to tvhawaii or any other person.

By “normal,” I am here referring to Tor exit nodes (as in the original discussion, before you changed the definitions and the argument) and that data transmitted from Tor exit nodes is safe for encrypted websites, since the encryption of the third party website is independent of the Tor service and is assumed to be secure.

So, what makes you think that the above conditions are met for tvhawaii or any other person? This admin has showed you at least two scenarios in which this was not true, and several scenarios which actually occurred in the recent years, so without knowing the power of the adversary that a person must face, those assumptions can't be held generally true. In particular, the assumption that encryption of the third party website is secure is totally irrelevant: actually the attack does not require to compromise the https website at all.

And even if “a” third party website certificate is not secure, then neither a VPN service nor Tor will protect you when connecting to this compromised website.

The https website is NOT compromised: this is the essence of the attack, and this is the reason for which using a VPN protects the victim. As already stated, currently the only know method to solve this problem for the attacker is only disrupting OpenVPN connections to the victim, thus alerting him/her.

All HTTP traffic, whether a VPN or Tor, can be sniffed in transit.

No, the real header and payload can't be unencrypted when inside the VPN.

So once again, your argument is incorrect.

You're free to believe what you want to believe.

Kind regards

[Anonymous Writer 2]

Let me preface my words thus:

I think we can all appreciate a VPN admin who is serious about privacy and who is zealous for knowledge. Indeed, it is a clear indication that AirVPN is a VPN created and maintained by activists, who are serious about Internet freedom and security.

Now, it is no secret that you and I, admin, do not see eye to eye on the issues we have been debating on this forum for sometime. And, I have no interest to continue it, since I do not see the point.

However, I suspect that, perhaps, there is a disconnect between us and perhaps we are not arguing dissimilar points. And so, I need clarification on two points, clear and conscise.

In regard to this statement

I wrote:

All HTTP traffic, whether a VPN or Tor, can be sniffed in transit.

You wrote:

No, the real header and payload can't be unencrypted when inside the VPN.

Now perhaps I was not clear on that statement but the context certainly was; in fact, I made it rather clear throughout my postings. And so I ask:

In what sense are you making that statement:

1) The initial connection from a client to a VPN server cannot be sniffed?

or

2) Unencrypted HTTP exit traffic from a VPN to a web server cannot be sniffed?

No one can dispute with the former, but I take serious argument with the latter. Perhaps you can elaborate which of the two you meant? The context of all my postings was about the latter, since encrypted traffic from a client to any encrypted server cannot be sniffed (excluding the debate with compromised, fraudulent, or hacked certificates or Man in the Middle Attacks involving fraudulent certificates).

Lastly, please elaborate on your position about OpenVPN.

You wrote:

Actually, currently the only way for the attacker to solve this "problem" is only disrupting completely OpenVPN connections.

Perhaps there is a misunderstanding here was well? My argument throughout my posts is that exit traffic from any service, including an OpenVPN server, is liable to a Man in the Middle Attack on route to a web server, even if the website is encrypted.

You seem to argue otherwise.

So please explain: In what sense shall we understand your words? Are you referring to:

1) The initial connection from a client to a VPN server?

or

2) Exit traffic from a VPN server to a web server?

If the latter, you are then suggesting that an OpenVPN service can protect users from a Man in the Middle Attack to a web server, whether encrypted or not?

Thank you.

[Staff 9773]

No, the real header and payload can't be unencrypted when inside the VPN.

In what sense are you making that statement:

Hello!

The http traffic "in transit" cannot be sniffed by your ISP or by a "man in the middle" (an entity between) the OpenVPN client and the OpenVPN server.

Kind regards