An article about how SSL is misused (or not used at all).
The point is that SSL itself is secure, and it's people whose mistakes and misunderstandings make SSL-protected resources vulnerable.
Monday, February 20, 2017
An article about how SSL is misused (or not used at all).
When you look at the average IT company, you see the front-end (the product it offers) and that's all. Many people wonder why the amount of personnel is so large, for the seemingly simple product? Well, there are several main reasons, which I list below.
1. Customer service and sales
2. Scalable Backend development
3. Research and optimization
4. Permanent security evaluation
5. Integration with others
1. Customer service and sales. This is the department (in IT companies it's often the same personnel for both tasks) that communicates with customers, prospects, and partners. It can be infinitely large, especially for a mass market product.
2. Scalable Backend development. Most (if not all) IT products (software) have a part, called back-end, which contains most of the business logic. For mass market products, this part must not just work properly, but also be scalable, i.e. be able to handle many requests concurrently. To do so, the backend runs on several computer systems simultaneously, and they must play nice with each other. such scheme of operations is called "distributed system". Design and maintenance of distributed systems are one of the most complicated tasks in IT industry, and there's always room for improvement in any distributed system.
3. Research and optimization. The efficiently designed and implemented system can perform much better, than humans, and human labor is nowadays much more expensive than computer systems. Thus it makes sense to put the most of the burden on computers. But their resources also have certain limits, and the more operations you can "fit" into a single system, the more commercially efficient and profitable (let's hope so :) your system is.
4. Permanent security evaluation. New ways to penetrate protection of computer systems are found and presented literally every day. This can lead to money loss or even more serious, even deadly threats. Obviously, this is not what any business would like to experience, so security evaluation, patching, further evaluation is the never-ending loop of work of IT security specialists.
5. Integration with others. IT systems rarely work in the isolated environment. Even when the software application works on the local computer, it is run on top of the operating system layer, and playing nice with the OS is a kind of integration as well. Now, the data must enter and leave the software system. Making this possible requires following certain standards, data exchange formats etc. All of this is also integration. Finally, the software rarely delivers the complete solution to some business problem. More often, the software is the part of the larger workflow and integrating into as many workflows as possible is important to deliver the better experience to customers and to grow the user base.
Wednesday, January 11, 2017
As I wrote a number of times, PKI's reliance on Certificate Authorities, which could possibly work 30 years ago when it was originally invented, doesn't perform well now, when the number of CAs has grown significantly, and it has become possible for a wide range of shady entities, both governmental and private, to become CAs or to issue CA certificates and make them trusted on customer computers. This includes hardware vendors (remember Superfish issue), antivirus software (check Kaspersky's root certificate issues), corporate proxies and more.
There's a need to check in some way, that the certificates presented during the connection, are the ones that the original server intended to send. It turns out that there's no standard way to do this, and the browser vendors are not looking for efficient ways to address the problem either. There's a great article on Computerworld, which lists some of the possible solutions for the problem, with descriptions and references. It contains a couple of simple yet easy to implement approaches, which beg for putting them into RFCs and similar standards. Instead, Google goes for implementing hard-to-enforce and hard-to-use approaches like Certificate Transparency Initiative. My vote goes to Certificate Validation Framework. Also, you can choose your favorite approach :).
Sunday, October 9, 2016
The very disturbing study, described in detail here, indicates that any security warning are not effective, cause in the worst case people simply not "trust" the warnings. I.e. they trust a fishing website more, than the respected developer of the web browser. Ok ...
I think that's the same reason people go for Trump in these elections.
Wednesday, October 5, 2016
The Chinese certificate authority WoSign used shady practices when issuing the certificates. To make things worse, it acquired the Israeli company named StartSSL and supposedly made it use WoSign's infrastructure. And that infrastructure was either misconfigured, or intentionally abused - we can only guess now.
Now, Apple has removed the root certificate of WoSign from its Trusted Roots. However, the WoSign's CA certificate is counter-signed by two other CAs, and that gives trust to the WoSign's CA. Without explicitly blocking this CA certificate neither Apple nor any other software vendor can't effectively prevent the abuse of the PKI infrastructure, when co-signing is used.
I was a proponent of the approach that certificates must be signed by more than one CA. This makes the system harder to compromise. But counter-signature must be validated using logical AND, not logical OR. One must require all three trusts to remain valid, rather than rely on any of the signatures, like in the above case.
I am wondering, how many security breaches should happen until the industry starts moving in the direction of requiring more than one valid signature on each certificate (or at least on CA certificates).
And I am afraid, that unless such movement is implemented in standards, we'll see vendors going in all directions implementing incompatible, if not mutually exclusive, approaches to strengthening PKI.
Full story here.