انواع رمزگذاری VPN | OpenVPN، IKEv2، PPTP، L2TP / IpSec، SSTP

اگر از رمزگذاری های مختلف در داده ها و کانال های کنترل استفاده می شود ، سپس قدرت واقعی اتصال OpenVPN توسط مجموعه رمزگذاری ضعیف تر مورد استفاده قرار می گیرد.

برای حداکثر امنیت ، هر دو داده. و رمزگذاری کانال کنترل باید تا حد امکان قوی باشد. با این حال ، رمزگذاری مورد استفاده هرچه قوی تر باشد ، اتصال آهسته تر خواهد بود ، به همین دلیل برخی از ارائه دهندگان از رمزگذاری کانال داده استفاده می کنند.

رمزگذاری کانال کنترل را رمزگذاری TLS نیز می نامند زیرا TLS فن آوری است که برای مذاکره ایمن ارتباط بین شما استفاده می شود. کامپیوتر و سرور VPN. این همان فناوری است که توسط مرورگر شما برای مذاکره ایمن در مورد اتصال به وب سایت رمزگذاری شده HTTPS استفاده می شود.

• رمزگذاری کانال کنترل شامل رمزگذاری ، رمزنگاری دستی و تأیید هویت است.
• رمزگذاری کانال داده شامل یک رمزگذار و

ارائه دهندگان VPN اغلب از همان سطح رمزگذاری برای کانالهای کنترل و داده استفاده می کنند. در بررسی ها و جداول "چراغ راهنمایی" ما ، فقط در صورت استفاده از مقادیر مختلف برای هر کانال ، آنها را جداگانه لیست می کنیم.

اگر بیان کنیم که ارائه دهنده از رمزنگاری AES-256 استفاده می کند ، این بدان معنی است که از رمزنگاری AES-256 استفاده می شود. هم برای کانالهای کنترل و هم برای داده ها. *

(* حداقل [این باید باشد. برخی بررسی های میراث دستورالعمل های فعلی ما را رعایت نمی کنند ، اما اینها باید به موقع فاز شوند). [19659160] Ciphers

OpenVPN می تواند از تعدادی رمزگذار کلید متقارن برای اطمینان از داده ها در کانالهای کنترل و داده استفاده کند. در عمل ، تنها کسانی که از ارائه دهندگان تجاری VPN استفاده می کنند Blowfish ، AES و (کاملاً به ندرت) کاملی هستند.

Blowfish

Blowfish-128 رمزگذاری پیش فرض است که توسط OpenVPN استفاده می شود. اندازه های کلیدی در تئوری می توانند از 32 بیت تا 448 بیت باشند ، اما Blowfish-128 تنها نسخه ای است که احتمالاً در طبیعت با آن روبرو خواهید شد.

Blowfish اغلب به اندازه کافی برای اهداف گاه به گاه ایمن در نظر گرفته می شود ، اما ضعف هایی را شناخته است. . این توسط رمزنگار مشهور بروس اشنر ساخته شده است ، که در سال 2007 گفت ، "در این مرحله ، اگرچه من متحیر هستم که هنوز از آن استفاده می شود."

از نظر ما ، استفاده از Blowfish-128 به عنوان خط دوم قابل قبول است. دفاع در کانال داده OpenVPN. با این وجود ، نباید از آن استفاده کرد كه در کانال كنترل استفاده شود.

AES

AES به رمزنگاری كلیدی متقارن "استاندارد طلای" صنعت گسترده VPN تبدیل شده است. AES دارای مجوز NIST است و تقریباً در سراسر جهان بسیار امن تلقی می شود. AES-256 توسط دولت ایالات متحده برای محافظت از داده های "ایمن" استفاده می شود.

این واقعیت که اندازه بلوک 128 بیتی دارد و نه اندازه بلوک 64 بیتی Blowfish ، همچنین به معنای این است که می تواند پرونده های بزرگتر را اداره کند (بیش از 4 گیگابایت ) بهتر از Blowfish. علاوه بر این ، مجموعه دستورالعمل AES از شتاب سخت افزاری داخلی در اکثر سیستم عامل ها بهره می برد.

AES معمولاً در اندازه های 128 بیتی و 256 بیتی در دسترس است (AES 192 بیتی نیز وجود دارد). AES-128 تا آنجا که هر کسی آگاه است ، امن می ماند. با توجه به آنچه اکنون می دانیم میزان حمله NSA به استانداردهای رمزنگاری ، با این حال ، اکثر کارشناسان موافق هستند که AES-256 حاشیه امنیتی بالاتری را فراهم می کند.

فقط برای اطمینان از این که هیچ کس این موضوع را خیلی راحت پیدا نکند ، هر چند ، بحث در مورد این موضوع وجود دارد. AES-128 دارای یک برنامه کلیدی قوی تر از AES-256 است ، که باعث می شود برخی از کارشناسان برجسته معتقد باشند که AES-128 در واقع از AES-256 قوی تر است.

اما اجماع عمومی این است که AES-256 قوی تر است.

کاملی

کاملی یک رمز امن مدرن است و حداقل به همان اندازه AES امن و سریع است. در اندازه های کلیدی 128 ، 192 و 256 بیت در دسترس است. به لطف صدور گواهینامه NIST و استفاده آن توسط دولت ایالات متحده ، با این حال ، AES تقریباً همیشه به جای کاملیا مورد استفاده قرار می گیرد.

اما همانطور که در زیر بحث می کنم ، دلایلی وجود دارد که به رمزهای معتبر NIST اعتماد نکنید. این واقعیت که Camellia یک رمزنگاری غیر NIST است دلیل اصلی برای انتخاب آن از طریق AES است. با این حال ، این گزینه فقط به ندرت در دسترس است.

همچنین شایان ذکر است که Camellia تقریباً به اندازه AES از نظر ضعف آزمایش نشده است.

رمزنگاری دستی

به منظور ایمن مذاکره در مورد اتصال بین دستگاه شما و یک سرور VPN ، OpenVPN از دست زدن به TLS استفاده می کند. این اجازه می دهد تا مشتری OpenVPN و سرور VPN کلیدهای مخفی را با آنها برقرار کنند.

برای محافظت از این لرزش ، TLS معمولاً از رمزنگاری کلید عمومی RSA استفاده می کند. این یک الگوریتم رمزگذاری و امضای دیجیتالی است که برای شناسایی گواهینامه های TLS / SSL استفاده می شود. با این وجود ، می تواند به جای آن از مبادله کلید Diffie-Hellman یا ECDH نیز استفاده کند.

RSA

RSA یک سیستم رمزگذاری نامتقارن است – از کلید عمومی برای رمزگذاری داده ها استفاده می شود ، اما از کلید خصوصی دیگری برای رمزگشایی استفاده می شود. آی تی. این 20 سال گذشته پایه و اساس امنیت در اینترنت بوده است.

اکنون به خوبی مشخص شده است كه RSA با طول كلیدی 1024 بیتی (RSA-1024) یا كمتر ایمن نیست ، و تقریباً مطمئناً توسط NSA شکسته شده است. در نتیجه ، یک حرکت هماهنگ بین شرکت های اینترنتی برای مهاجرت به دور از RSA-1024 اتفاق افتاده است.

متأسفانه ، ما هنوز هم می یابیم که برخی از خدمات VPN برای محافظت از لرزش دست از استفاده از RSA-1024 استفاده می کنند. این خوب نیست.

RSA-2048 و بالاتر هنوز هم امن در نظر گرفته شده است. RSA به خودی خود رازداری عالی (PFS) را ارائه نمی دهد. با این وجود ، این امر می تواند با استفاده از مبادله كلیدی Diffie-Hellman (DH) یا منحنی الیپتیك (Difference-Hellman) و دیفی دی هلمن (ECDH) در مجموعه رمزنگاری آن اجرا شود.

در این حالت ، قدرت کلید DH یا ECDH مهم نیست. همانطور که از فقط استفاده می شود تا محرمانه ای عالی برای پیشبرد فراهم کند. این ارتباط با استفاده از RSA امن شده است.

از آنجا که می تواند باعث سردرگمی شود ، من همچنین توجه خواهم کرد که رمزنگاری RSA هیچ ارتباطی با شرکت فناوری ناسازگار آمریکایی RSA Security LLC ندارد. این شرکت پس از رشوه دادن 10 میلیون دلار توسط NSA ، به طور عمدی محصولات رمزگذاری شده BSAFE پرچمدار خود را تضعیف کرد.

Diffie-Hellman و ECDH

رمزگذاری دستی دیگری (رقیب) که بعضا توسط OpenVPN مورد استفاده قرار می گیرد ، Diffie-Hellman (DH) است. تبادل کلید رمزنگاری. این معمولاً دارای طول کلیدی 2048 بیت یا 4096 بیت است. توجه داشته باشید که از هر چیزی کمتر از DH-2048 به دلیل مستعد بودن در حمله لجگرام باید اجتناب شود.

مهمترین مزیت دستی که دیفی دی هلمن نسبت به RSA دارد این است که بومی رازداری عالی را ارائه می دهد. همانطور که قبلاً نیز اشاره شد ، با اضافه کردن مبادله کلید DH به دستی RSA به یک نتیجه مشابه می رسد.

Diffie-Hellman باعث اختلاف نظرهای زیادی در مورد استفاده مجدد از تعداد محدودی از شماره های اصلی شده است. این امر باعث می شود كه در برابر یك مخالف قدرتمند مانند NSA در معرض خطر قرار نگیرند. بنابراین ، دیفی هلمن برای رمزنگاری دستی دستی را ایجاد نمی کند. اگرچه به عنوان بخشی از مجموعه رمزنگاری RSA استفاده می شود ، خوب است.

منحنی بیضوی Diffie-Hellman (ECDH) یک شکل جدیدتر از رمزنگاری است که در برابر این حمله آسیب پذیر نیست. این امر به این دلیل است که از ویژگیهای نوع خاصی از منحنی جبری به جای اعداد اصلی بزرگ برای رمزگذاری اتصالات استفاده می کند.

ECDH را می توان به عنوان بخشی از دستی RSA برای فراهم آوردن رازداری کامل Forward Forward استفاده کرد ، یا می تواند دستی را روی آن رمزگذاری کند. خود (با امضای ECDSA). This also provides PFS.

ECDH key length starts at 384-bits. This is considered secure, but when used on its own to secure a TLS handshake, the longer the better (in terms of security, anyway).

SHA Hash Authentication

This is also referred to as data authentication or hash message authentication code (HMAC).

Secure Hash Algorithm (SHA) is a cryptographic hash function used (among other things) to authenticate data and SSL/TLS connections. This includes OpenVPN connections.

It creates a unique fingerprint of a valid TLS certificate, which can be validated by any OpenVPN client. Even the tiniest change is detectable. If the certificate is tampered with, this will immediately be detected and the connection refused.

This is important in preventing a Man-in-the-middle (MitM) attack, where an adversary attempts to divert your OpenVPN connection to one of its own servers instead of your VPN provider. It could do this, for example, by hacking your router.

If an adversary can crack the hash of your provider’s genuine TLS certificate, it can reverse the hash to create a forged certificate. Your Open VPN software would then authenticate the connection as genuine.

Is SHA Secure?

When used to protect HTTPS websites, SHA-1 is broken. This has been known about for some time. SHA-1 websites can still be found, but are being phased out. Most browsers will now issue a warning when you try to connect to a website secured with SHA-1.

SHA-2 and SHA-3 hash functions are now recommended instead, and are secure. SHA-2 includes SHA-256, SHA-384, and SHA-512. However…

OpenVPN only uses SHA for HMAC. I don’t think it useful to go into too much detail here, but SHA hash authentication is part of the HMAC algorithm. Attacking HMAC embedded with SHA-1 is much harder than just attacking the SHA-1 hash function itself.

In other words, HMAC SHA-1 as used by OpenVPN is considered secure and there is Mathematical proof of this. Of course, HMAC SHA-2 and HMAC SHA-3 are even more secure! Indeed, the recent OpenVPN audit recognizes that HMAC SHA-1 is secure, but recommends transitioning to HMAC SHA-2 or HMAC SHA-3 instead.

Notes

NIST

AES, RSA, SHA-1, and SHA-2 were all developed and/or certified by the United States National Institute of Standards and Technology (NIST). This is a body that by its own admission works closely with the NSA in the development of its ciphers.

Given what we now know of the NSA’s systematic efforts to weaken or build backdoors into international encryption standards, there is every reason to question the integrity of NIST algorithms.

NIST, of course, strongly refutes such allegations:

“NIST would not deliberately weaken a cryptographic standard.”

It has also invited public participation in a number of upcoming proposed encryption standards, in a move designed to bolster public confidence.

The New York Times, however, accused the NSA of circumventing NIST-approved encryption standards by either introducing undetectable backdoors or subverting the public development process to weaken the algorithms.

This distrust was further bolstered when RSA Security (a division of EMC) privately told customers to stop using an encryption algorithm that reportedl y contains a flaw engineered by the NSA. This algorithm had also been endorsed by NIST.

Furthermore, Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) is an encryption standard engineered by NIST. It has been known to be insecure for years.

In 2006 the Eindhoven University of Technology in the Netherlands noted that an attack against it was easy enough to launch on “an ordinary PC.” Microsoft engineers also flagged up a suspected backdoor in the algorithm.

Despite these concerns, where NIST leads, the industry follows. Microsoft, Cisco, Symantec, and RSA all include the algorithm in their product’s cryptographic libraries. This is in large part because compliance with NIST standards is a prerequisite to obtaining US government contracts.

NIST-certified cryptographic standards are pretty much ubiquitous worldwide, throughout all areas of industry and business that rely on privacy. This makes the whole situation rather chilling.

Perhaps precisely because so much relies on these standards, cryptography experts have been unwilling to face up to the problem.

AES-CBC vs AES-GCM

Until recently the only AES cipher that you were likely to encounter in the VPN world was AES-CBC (Cipher Block Chaining). This refers to the block cipher mode, a complex subject that is not really worth going into here. Although CBC may theoretically have some vulnerabilities, the general consensus is that CBC is secure. CBC is, indeed, recommended in the OpenVPN manual.

OpenVPN now also supports AES-GCM (Galios/Counter Mode).

• GCM provides authentication, removing the need for a HMAC SHA hashing function.
• It is also slightly faster than CBC because it uses hardware acceleration (by threading to multiple processor cores).

AES-CBC remains the most common mode in general use, but we are now beginning to encounter AES-GCM "in the wild." Given the advantages of GCM, this trend is only likely to continue. From a cryptographic perspective, tho9ugh, both AES-CBC and AES-GCM are very secure.

OpenVPN UDP vs. OpenVPN TCP

OpenVPN can run over TCP (Transmission Control Protocol) or UDP (User Datagram Protocol).

• TCP = reliable. Whenever a computer sends a network packet using TCP, it waits for confirmation that the packet has arrived before sending the next packet. If no confirmation is received, it will resend the packet. This is known as error-correction. There is “guaranteed delivery” of all data, but it can be quite slow.
• UDP = fast. Using UDP, no such error correction is performed. Packets are simply sent and received with no acknowledgments or retries. This makes UDP much faster than TCP, but less reliable.

If given the choice, I suggest using the faster UDP protocol unless you experience connection problems. This is the default strategy adopted by most VPN providers.

Defeat Censorship with OpenVPN on TCP Port 443

One of the great advantages of OpenVPN is that it can be run over any port, including TCP port 443. This is the port used by HTTPS, the encrypted protocol that secures all secure websites.

Without HTTPS, no form of online commerce, such as shopping or banking, would be possible. It is therefore very rare for this port to be blocked.

As an bonus, VPN traffic on TCP port 443 can be routed inside the TLS encryption in the same way as is used by HTTPS. This makes it much harder to spot using advanced Deep Packet Inspection techniques. TCP port 443 is, therefore, the favored port for evading VPN blocks.

Many VPN providers offer the ability to change the port number used by OpenVPN using their custom software.

Even if yours does not, many VPN providers do actually support OpenVPN using TCP port 443 at the server level. You can switch to it with a simple edit to your OpenVPN configuration (.ovpn) file. It is, therefore, worth asking your VPN provider about this.

It is worth noting that network engineers dislike this tactic as TCP over TCP is very inefficient. When it comes to defeating censorship, however, it often works.

SSTP uses TCP port 443 by default.

Summaries

VPN Protocols

• PPTP is very insecure and should be avoided. While its ease of setup and cross-platform compatibility are attractive, L2TP/IPsec has the same advantages and is much more secure.
• L2TP/IPsec is a good VPN solution for non-critical use. This is especially true on legacy devices that do not support OpenVPN. It has, however, been severely compromised by the NSA.
• SSTP offers most of the advantages of OpenVPN, but is primarily only a Windows protocol. This does mean that it is better integrated into the OS, but it is poorly supported by VPN providers thanks to this limitation. In addition to this, its proprietary nature and the fact that is was created by Microsoft mean that I, for one, don’t trust it.
• IKEv2 is a very good (secure and fast) protocol. Mobile users, in particular, may even prefer it to OpenVPN due to its improved ability to reconnect when an internet connection is interrupted. For Blackberry users, it is pretty much the only option available. Use open-source versions where possible.
• OpenVPN is the recommended VPN protocol under most circumstances. It is fast, reliable, secure, and open source. It has no real downsides, per se., but to be truly secure it is important that it is implemented well. This means use of strong encryption with Perfect Forward Secrecy.

OpenVPN Encryption

When it comes to encryption, the devil is in the detail. It is common to see VPNs providers say they use “ultra-strong 256-bit” AES OpenVPN encryption, but this does not, in reality, tell us very much. AES-256 is indeed a strong cipher, but if other aspects of the encryption suite used are weak, then your data will not be secure.

• Cipher – this protects your actual data. AES-256 is now the industry standard and is recommended.
• Handshake – this secures your connection to the VPN server. RSA-2048+ or ECDH-384+ are secure. Importantly RSA-1024 and Diffie-Hellman handshakes are not.
• Hash authentication – creates a unique fingerprint, which is used to validate data and TLS certificates (that is, to check that the server you are connecting to really is the one you think you are connecting to). HMAC SHA-1 is absolutely fine, but HMAC SHA-2 (SHA-256, SHA-384, and SHA-512) and HMAC SHA-3 are even more secure! Note that hash authentication is not required if the AES-GCM cipher is used.
• Perfect Forward Secrecy (PFS) – this ensures that new encryption keys are created for each session. OpenVPN should not be considered secure unless PFS is implemented. This can be done either by including a Diffie-Hellman or ECDH key exchange in an RSA handshake, or a DH or ECDH handshake.
• Encryption is only as secure as its weakest point. This means that encryptions settings should be strong on both the data and control channels.
• Using higher bit lengths for ciphers and keys is almost always more secure, but this comes at a cost in speed.

OpenVPN will negotiate ciphers between client and server at will. Unless very specific parameters are defined, OpenVPN may default to weak settings. At a minimum, OpenVPN will default to Blowfish-128 cipher, RSA-1024 handshake with no PFS, and HMAC SHA-1 hash authentication.

Conclusion

Hopefully, you now have a better understanding of what makes for a secure VPN connection. When it comes to properly configuring a VPN, however, encryption is only half the story. The other half is ensuring that no traffic enters or leaves your computer outside of the VPN connection.

To learn more about this, please check out our Complete Guide to IP Leaks.