Ivan Ristić

then i totally misunderstood how squid bypasses ssl.
My understanding is that:
After building a TCP connection, the SSL handshake is started by the client and sends which version of TLS it knows.
The server then picks a compatible cipher and compression method. and then sends its certificate.
This certificate must be trusted by either the client itself or a party that the client trusts(a certificate authority). In this context the word 'trust' means that the client has the public key that can decrypt the certificate. For example, if the client trusts GeoTrust, then the client can trust the certificate from Google.com because GeoTrust used its private key to cryptographically sign Google's certificate and my browser has the public key for Geotrust.

How SQUID enables SSL failure is obscure to me because the failure of SSL is complicated and this slide is overwhelming
https://blog.ivanristic.com/SSL_Threat_Model.png

SQUID is a proxy for the website you want to access - so when your browser negotiates the TLS handshake it's really talking to SQUID who then talks to the website if necessary. So how does your browser get directed to an illegitimate proxy? The only way I can imagine is if the DNS is bad but I don't see how that can happen.
So for example you want to go to google.com Your browser goes out to your DNS (the ip you plugged in to the network configuration settings) and gets the ip for google. How can someone interpose squid between you and google ?

And then even if…

A few of my favoriates from my RSS reader (in no particular order) include:

- http://www.kalzumeus.com/blog/ I love reading anything by Patrick McKenzie because he writes about incredibly valuable things, usually focusing on how to make sales, lifecycle emails, running his companies, and other general start-up related information. You might recognize him on HN as patio11

- https://blog.cloudflare.com/ CloudFlare has really excellent content and often writes about SSL/TLS related topics, which personally interest me. They have good technical explanations of SSL/TLS vulnerabilities and discuss how they provide SSL to all of their customers. Also, they discuss how they handle massive scale and other interesting things.

- https://aws.amazon.com/blogs/aws/category/week-in-review/ I often find really good articles linked from the AWS blog. I like to stay current on the latest/greatest features and improvements which AWS puts out there and the Week in Review posts are often easy to skim and see if a linked article is worth reading in its entirety.

- https://codeascraft.com/ Etsy's engineering blog is fantastic. I am always blown away at the passion that comes through from their posts. They seem to have a really sharp set of devs over there and I just enjoy reading their stuff. I especially enjoy the quarterly performance review posts, which show graphs about latencies throughout their stack.

- https://strongloop.com/ The StrongLoop blog has some really great content for NodeJS…

> .. for no apparent reason by the WireGuard developers...

It's a very weird assertion that the Wireguard devs just threw the software together at random, choosing parameters for "no apparent reason".

> What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?

TLS is famously susceptible to downgrade attacks. (https://blog.ivanristic.com/2013/09/is-beast-still-a-threat.html etc.)

Ultimately, it's a value judgement. You can either have resistance to downgrade attacks (which have themselves proven to be quite problematic), or you have interoperability across multiple versions and configurations of endpoints. Increase the configurability of the protocol, and you massively increase the complexity. Increased complexity means increased testing burden and ultimately increased risk.

If Wireguard needs to be fixed in a backwards-incompatible way, then we'll find ourselves with a new version of Wireguard that doesn't work with the old version.

Reproducing an earlier comment I made on Reddit (http://www.reddit.com/r/netsec/comments/1mn2nk/ssltls_deployment_best_practices/ccarooh):

If you want the short version for Apache, Nginx and OpenSSL: http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

For those who don't give a shit if Windows XP / IE can establish an SSL connection with you, here's a cipher string without RC4.

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

More details, including the configurations for SSL/TLS protocol versions, can be found at the link above.

For me, the best part of this release is the fact that the TLS stack has been significantly improved, and is now quite good. The lack of some critical features in Java 7 (e.g., inability to enforce cipher suite order) made TLS effectively unusable.

The list of improvements is quite long, actually:

- Server Cipher Suite Preference

- Strong Server Ephemeral Diffie-Hellman Parameters

- Authenticated (GCM) Suites

- Hardware Acceleration on Intel and AMD processors

- Server-Side SNI Support

- Ability to disable client-initiated renegotiation

- TLS 1.2 enabled by default in client mode

- Clients support Ephemeral DH over 1024 bits

More details here: http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-java-8.html

And there are more security improvements documented here: http://openjdk.java.net/projects/jdk8/features#core/sec

For those who care about copyright, that URL is not from O’Reilly; it’s a copy of a book-set that O’Reilly used to distribute via CD-ROM – with a nice user interface that used web technologies (even included a search feature). O’Reilly could make it available for free – as they’ve done so for other books such as Apache Security¹ or Using Samba² – but they still (as is their right) expect you to pay for the sed & awk book³.

¹ https://blog.ivanristic.com/2015/02/apache-security-ten-years-later.html

² https://www.oreilly.com/openbook/samba/book/

³ https://www.oreilly.com/library/view/sed-awk/1565922255/