You are interested in Internet privacy and You are using traditional old style IPsec or OpenVPN based tunneling protocols like IKEv1/IKEv2 or TLS which techologies coming from 90-ies. Big packet headers, lots of RTT-s, vast crypto libraries as openssl,  weak encryption algorithms and security issues. Look at my talk and presentation in Cyberchess2019 conference (in Latvian) and appreciate next generation IP tunneling protocol WireGuard and compare it against old style VPNs.  You could choose WireGuard clients as TunSafe for Windows 10, WARP from Cloudflare for Android and iOS with odd DoH/DoT! Good Luck!

Automatic SSL configuration generator

Configuring TLS is perhaps the most complicated and error-prone of all IT tasks, and this tries to make it as easy as possible. Mozilla recently developed and released SSL/TLS configuration generator

ssl-config.mozilla.org

Selfie reflection attack against TLS 1.3 with PSK(Pre-Shared Key)

This attack affect psk_ke and psk_dhe_psk key exchange modes. This attack don't compromise communication channel's confidentiality and integrity.

If Alice share key with Bob, Eve could redirect TLS handshake packets back to Alice and Alice will send data himself such as: "If you have the file data.txt you can delete it. I hold a copy." If Alice, Bob and Carol share same PSK and Alice send data to the Bob, Eve could redirect TLS traffic to the Carol. In such situation Alice don't know actually that she speaks withs Carol. Selfie authors recommends using external PSK in conjuction with certificates or enforce user identification, which isn't easy task. To avoid need to using certificattes Selfie authors recommend:

"A PSK MUST NOT be shared between more than one client and one server."

Actually here is question, how wide external PSK are used. As PSK avoid using public key operation, this is useful in performance-constrained environments with limited CPU power. From practial viewpoint Selfie attack affects very small percentage of TLS commmunity (who use TLS-PSK nowadays!):

- CDN nodes acting as proxies

- P2P networks

- WiFi networks relying on one PSK

I familiarized with Smart-ID technical overview and pay attention to the signature computation. From quick overview of detailed description of signature scheme, I infer usage of Distributed Multiprime RSA composite signature (client and Smart-ID server). Brilliant idea ... but with outdated and flawed signature implementation with RSASSA-PKCS1-v1_5 from RFC 3447. Inventors of Distributed Multiprime RSA strongly discourage usage of such weak signature implementation: "In practice RSA is never used without a secure padding scheme, such as PSS-RSA for signatures or OAEP-RSA for encryption. As show by Bleichenbacker's attack [Ble98] on the PCKS#1 v1.5 standard, provable security of RSA in combination with the padding scheme is very important." Developers of Smart-ID signature scheme didn't follow to inventor's recommendations and best practices. Other security researchers also indicate RSASSA-PKCS1-v1_5 to be vulnerable to the side-channel attacks.