ivanr

24 ms·

211.
SSL/TLS capabilities of 30+ widely used browsers and devices(dev.ssllabs.com)
4 points by ivanr 12y ago|0 comments
212.
by ivanr 12y ago
Tim's rant is misplaced. The reason he can't connect to https://keybase.io using Java 7 is because Keybase have (mis)configured their server so it doesn't offer any cipher suites Java 7 could use. https:/&#x
213.
by ivanr 12y ago
Well, it depends. You shouldn't include subdomains if you have some that do not support HTTPS. That would be an instant self-inflicted denial of service attack. However, for best security, you must include subdomains. Because the cooki
214.
by ivanr 12y ago
Just to be clear, my books mentioned in the blog post (Bulletproof SSL and TLS and OpenSSL Cookbook) are most certainly not out of date. In fact, they are a rare example of books that are continuously maintained. I pledged to maintain them
215.
by ivanr 12y ago
There should be a clear statement about the status of Convergence on the web site. IIRC, the Firefox extension has been broken for more than a year now. Why? If Mozilla broke their APIs and made it impossible for the extension to work, then
216.
by ivanr 12y ago
Indeed, short-lived certificates do seem like a solution to this problem. One downside might be the fact that (anecdotally) many users have inaccurate clocks. I read somewhere recently that a large web site has to back-date their new certif
217.
by ivanr 13y ago
Yes, but there are other ways to compromise TLS sessions. For example, if you're using session tickets, the ticket key could be in RAM. Or, the session master keys themselves could be leaked. Still, you're _much_ better off with F
218.
HTTPS mixed content: still the easiest way to break SSL(blog.ivanristic.com)
5 points by ivanr 13y ago|0 comments
219.
by ivanr 13y ago
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 u
220.
Significant SSL/TLS improvements in Java 8(blog.ivanristic.com)
8 points by ivanr 13y ago|0 comments
221.
by ivanr 13y ago
Yes, we can agree that owning the entire platform is worse. But my point is that you can't ever achieve that without someone noticing. Think millions of devices. The malware would have to work flawlessly across a number of versions, in
222.
by ivanr 13y ago
The ease with which a bug can be exploited has everything to do with its impact. Exploiting buffer overflows is messy, requires a lot of effort, and it's detectable. Thus, you are more likely to use it for something special. Apple&#x27
223.
by ivanr 13y ago
No, the issue is not with the trust paths. The old 1024-bit root is in Mozilla's trust store, where it's a danger to everyone. SSL Labs reuses their store, which is why the weak root shows up in the trust paths. Technically, the F
224.
by ivanr 13y ago
I guess that some decisions are easier to make than others. It's quite clear, for example, that protocols before TLS 1.2 are inadequate. Forward Secrecy, on the other hand, is supremely important for some sites (e.g., Google) and not a
225.
by ivanr 13y ago
It's possible in some cases. For example, most sites continue to support SSL v3, even though only very old clients do not support TLS v1. So now would be a good time to tell those clients that they need to upgrade. If we don't do
226.
by ivanr 13y ago
Yes, that would be nice. I've heard that PolarSSL has per-protocol suite selection. It's really something the underlying SSL library needs to support. With OpenSSL, the best we can do right now is prioritize suites so that SHA2 on
227.
by ivanr 13y ago
Some comments: - You don't need the builtin session cache. According to the Nginx documentation, it's more efficient to rely only on shared memory alone. - You should use a longer session duration. Five minutes is too short. Use a
228.
by ivanr 13y ago
I wish that too. I don't like the idea of having a demonstratively weak cipher in my SSL configuration, either. On the other hand, RC4 remains the only reliable way to defend against BEAST. Modern browsers might have addressed this iss
229.
by ivanr 13y ago
It used to. As far as I know RHEL 6.5 was the first to enable Elliptic Curve cryptography by default. Fedora 18 and later were updated to support it, too. For more details, see here: https://bugzilla.redhat.com/show_bug.cgi?
230.
by ivanr 13y ago
Like it or not, sometimes it's necessary to choose the less of two evils. There was a time when BEAST was the best known attack against SSL, RC4 was not thought to be as weak as it is today, and RC4 was the only way to mitigate BEAST s
231.
by ivanr 13y ago
If you're stuck with Apache 2.2.x (and thus no support for Elliptic Curve crypto), perhaps you should give TLS Interposer a try: https://netfuture.ch/tools/tls-interposer/ It adds ECDHE support without having
232.
by ivanr 13y ago
Ideally, you should always use "includeSubdomains" with HSTS. This will provide robust security for the main hostname as well as all subdomains. The issue here is that (without "includeSubdomains") a man in the middle at
233.
by ivanr 13y ago
You have robust Forward Secrecy, so nothing to worry about. (I use the term "robust" to mean that you support both ECDHE and DHE suites, providing Forward Security to a wide range of clients) Before, there used to be a note at the
234.
by ivanr 13y ago
It's 180 days (or 15,552,000 seconds) at the moment. I have it documented in the rating guide, but I should probably mention it somewhere in the report. I am not sure that's long enough, by the way. There are some important sites
235.
SSL Labs: Stricter security requirements for 2014(blog.ivanristic.com)
103 points by ivanr 13y ago|56 comments
236.
by ivanr 13y ago
The compression-related issue in the TLS protocol is known as CRIME. BREACH actually applies to HTTP response body compression. So, chances are that you should continue to use the breach-mitigation-rails gem, even if your server does not su
237.
by ivanr 13y ago
There's a commit from about 2 hours ago that enables 1/n-1 detection. So perhaps that's what they are running now. But it does not seem to be implemented correctly: when I access the site with a Java client (which does implem
238.
by ivanr 13y ago
Correct. Firefox and all other modern browsers use the so-called 1/n-1 split technique to mitigate the BEAST attack. It's actually possible to test if the mitigation is present; it's just that this site has not implemented it
239.
by ivanr 13y ago
SSL Labs also has a client test: https://www.ssllabs.com/ssltest/viewMyClient.html And, if you're curious about client-side SSL support in general, every server test page simulates about 20 most popular (or import
240.
by ivanr 13y ago
Just as a side comment, optimisations to the attack paths are unlikely to make a substantial impact on overall performance, given that attack requests are only a fraction of all requests processed at any given time. (Excluding DoS, of cours

More ›