Recently, someone asked how to be 100% sure no transmission eavesdropping can happen. VPN providers are not secure as they do require to pass the encryption keys to authorities, thus all the data is stored in form of TCP Dumps according to local data retention policies. Is this standard unbreakable? No. Here is the approach how to overcome this problem creating state of the art secure TCP networking.
Want a secure transmission? Here is a simple one. Nothing more then IPSec, Multiple Wan's and 802.3ad Link Aggregation will create a total headache to anyone trying to decrypt the communication :)
Have a fun :) Rest assured this networking setup will leave no reconstructable traces in tcpdumps. It's simple, it's clean, and it works like a charm.
Data retention? Totally bypassed, unless someone has a lot of free time, measured in years. For decades, add some more ports :)
Best Regards,
S.
You should read about when people thought there was a backdoor in OpenBSD's ipsec stack's code.
Aware of it. (20 years old thing)
That old fact is based on strategy most of OpenBSD code come as a reverse engineering / ports of BSD itself. For a long time, BSD and RedHat was a channel for implementing exploits through code ports.
In the case of Gregory Perry, it's not the first nor the last time he tried to gain some publicity for his "ethical doings"...However, it he was ethical, he would not sign NDA for such project in the first place, rather then waiting 10 years to "deal ethically". NDA does not apply in criminal activity and law breaches, so the whole story of the guy is a bit cheap talk, since that NDA was illegal itself and can't stand on any court - nor the FBI would ever push that to trial at the cost of raising public concerns. Moreover, NDA could not be signed for period more then 5 years dating the end of employment (the court practice).
That, however does not goes against the fact that BSD and RedHat was a primary channel of "infecting" other open source projects at the time, as most vulnerabilities got ported along with the code, and was sneaky enough to simply got missed in the process. That way, vulnerabilities was introduced by people who were totally unaware what they are doing, while in fact, you can't attack gov. agencies for exploits in commercial products accepting these terms within the user agreements. Just take a look at RedHat user agreement. It's not gov to blame that someone ported the code from RedHat or BSD directly breaching the license and pull the vulnerability within the port.
Lucky enough, today distro maintainers pays much more attention due to fact you presented.
All he need to do is admit that his company induced the vulnerability by porting the code without even looking at what they are porting, rather then presenting as "Ethical guy"...
The distros his company created for Internal FBI use, is whole another story. But again, used to present as a nice guy after loosing much of credibility in both public and gov sector.
Yeah from what I read this guy just wanted to make a quick buck.
I like the direction where OpenBSD is going now with all the weird experimental security features they are trying in the kernel etc. I hope this kind of thing won't ever happen again :) Thanks for thorough comment. I assume you have been Defcon and are probably a big BSD fan :)
I like how it's heading too, but actually I'm not the fan of Defcon nor BSD at all :)
As stated, BSD has been used for a while as a method to put sneaky vulnerabilities that indirectly finish in OpenSource projects through ports, making it close to impossible to accuse gov. agencies for them, since porting is not fully legal. It was a sneaky way to infect other distros. Even Apple dropped their line of products such as Time Capsule / AirPort express (BSD based) over many flaws they were unable to control. I would say it needs to take time to get my confidence back. Personally, I prefer Gentoo for mission critical systems, or Debian for less sensitive work.
Def Con, again, too much gov. sponsored. It's close impossible to present something that really affects millions of users. Such as: https://hal.archives-ouvertes.fr/hal-01759199/document :)
When I demonstrated the ability to forward any mobile number through SS7 flaws at GSMA / MWC back in 2013 in front of security audience, the unofficial talks with Def Con reps was something like "It's far better to push MNO's to fix the issues, rather then cause a pandemic attacks by making it further publicly visible". - Right :) If I found some flaws in ZTE or Huawei, that would probably get into the headlines. Millions of affected users - who cares :) It was not the flaw, it was the design.
But not much into it lately. Assuming you were poking about being a fan of BSD and def-con :)
This pic from NSA I hunt sysadmins sums up my view of Defcon, also there is lots of NSA and FBI there.(GCHQ is also probably there and they can die in a fire)
I volunteer at a security con in my area every year, but its mostly organized by like minded people , I also started a security meetup , but I'm hardly involved anymore.
I actually trust the BSD's more than Linux, I hear what you are saying about BSD, but remember Linux is not immune to security issues being purposefully inserted into the distro in whatever way. Did you forget about this one: https://www.schneier.com/blog/archives/2008/05/random_number_b.html? :)
I am not longer a Gentoo person, sorry to say. I was involved in anapnea.net back in the day, just as a lurker mostly. So I've had my fair dose of Gentoo. I like Grsecurity, this is probably the most real Linux security related project and they are definately doing something right, otherwise they wouldn't be getting such harsh reactions from the rest of the world.
What a shame it's so hard to do for average users.
Agree, but it's not the average user who is a target of post.
I think Steemit needs to attract professionals, researchers and academic community as well. Right now, we lack that segment outside of steemdev group / Gridcoin team members etc. I don't want to offend anyone, there are some high quality works in photography, but let's be honest, that category is full not because of artistic value only, but due to a fact that anyone can push the camera button.
The way I see it, is that we can eventually attract cyber security professionals as well and form some expert groups here. That's why when I post something on specialized cyber security research networks, I do that here as well.
Maybe it won't get noticed at the time, but eventually someone will find one day and provide his inputs. More diverse community is good for the health of steemit, and honestly, I can't afford time to fight with 500+ SBD photo posts upvoted by tons of bots, while posts such as this one can eventually create direct business leads for me, and benefit for those who want to learn something or discuss computer networking and security.
Such as example of @adarshh question bellow.
IDD. However while reading your reply I wondered if a home user could get a similar effect using 4 VPNs and using a similar link aggregation technique.
Do you think a small device could be built for p2p applications to do that for home users?
Yes, I was actually thinking about this as a product, but unfortunately regulations are tricky (for a commercial service). However, it's relatively easy to setup. The cheapest and most affordable way to do it is any MikroTik device. RouterOS can set any number of ports as WAN's, and do multiple VPN connections with bonding support and full routing exposure. I would say that two $50 cheapest MikroTik boxes could make this setup easily. I have experimented on their carrier grade CCR models, but in basic, same RouterOS is on all of their devices with same feature set. There's no need for any license level that does not come with their cheapest offering.
Here's one fully suitable to support home setup according to scheme above:
https://mikrotik.com/product/hap_ac2
It can even expose the VPN bonding to home WiFi
so, it is a combination of IPSEC where they cannot figure out which application level connection the data is coming from and the fact that the same application data is dispersed over multiple connections, right? theoretically does it mean that if the interceptor knew how many vpn connections you are using and he has the VPN key for each connection then it is possible for them aggregate it back together by just directing all the VPN streams to their own aggregator appliance?
Yes, yes and yes. In theory, all he needs is all the dumps with encryption keys of each of connections.
In practice it gets a bit tricky. First, we are dispersing according to layer2 hashing policy, encrypted traffic via various ports of the bonding without any rule (pseudo round-robin). If TCP retransmission occurs, the ACK is not getting back, and the same packet is being transmitted on another port member. That will make same packet encrypted with another key, making it impossible for statistical analysis in order to derive key. Setting different MTU on each port will make this a nightmare as retransmission of same packet of different size will take place, while the aggregation of bandwidth will take care there's no strong impact over the huge retransmission.
With site-to-site GRE setup such as this one, IKE initiation is crucial if one want's to eventually reconstruct who is communicating with who within the encrypted domain, making it close to impossible without having raw dumps since the beginning of communication of each bonding member port. And if connection drops, which is expected to happen more frequently due to retransmission, remaining ports will take over - while the dropped one get's established again. (New IKE, news Timestamps, both phase 1 and phase 2).
As a result, not only keys are needed, but keys generated every-time the member port get's dropped, which is going to be unique. The connection will be persistent without any service degradation since aggregation compensate dropped member, and we can expect all 4 to get dropped constantly but hardly at the same time.
With the statistical analysis (Frequency Analysis, the scientific term) is impossible as a method to derive keys, even if someone does that somehow, it would take him the hell of the headache to reconstruct the communication. In practice, the chances to succeed are close to impossible. Take into account the example uses 4 Wans. Each additional port member will make it exponentially harder, and not only you can put more wans in real time, you can do multiple port members on single GRE to make it even worst.
You are theoretically right, but in practice, even if attacker manage to get the dumps of all eight ISP's in two different countries (very unlikely that all of them keep the whole dumps, as it's nowadays cheaper for small ISP's to pay the fines then store that much data), the real problem begins once he has it all.
But, In order to know if it has it all, he needs to decrypt whole communication, which is impossible without having it all. Or, If you like, "where's the can opener - inside the can" :)
Chances of reconstruction are so small that we can safely assume they are zero.
Is this how VPN works nowadays?
Not at all, this setup involved 4 VPN links, via 4 different providers with packets splitting via each of them to prevent reconstruction.
Standard VPN is not a protection, since ISP needs to store all the raw data according to retention policies. This solution aims to solve that problem. Also, most of VPN providers needs to pass the encryption key under condition of court order, making VPN useless. In this case, even with court order reconstruction is close to impossible.
Congratulations @crt! You have received a personal award!
Click on the badge to view your Board of Honor.
Do not miss the last post from @steemitboard!
Participate in the SteemitBoard World Cup Contest!
Collect World Cup badges and win free SBD
Support the Gold Sponsors of the contest: @good-karma and @lukestokes