Category: Security

Categories
Security Tech

Black Mirror in real life – Chinese public credit scores

China, and specifically Shanghai for now, is instituting public credit scores to rank citizens by various factors. The end goal to improve the behavior of people by ranking them publicly. This has to have been in the works for awhile. Did Black Mirror just steal the plot for Nosedive from what China is actually doing?

Quite a few places are reporting it and here’s the NRP version. I read it first in the Economist weeks ago so they should get credit for breaking it really but NPR reminded me. A quote from NPR’s version:

“We want to make Shanghai a global city of excellence,” says Shao Zhiqing, deputy director of Shanghai’s Commission of Economy and Informatization, which oversees the Honest Shanghai app. “Through this app, we hope our residents learn they’ll be rewarded if they’re honest. That will lead to a positive energy in society.”

Shao says Honest Shanghai draws on up to 3,000 items of information collected from nearly 100 government entities to determine an individual’s public credit score.

A good score allows users to collect rewards like discounted airline tickets, and a bad score could one day lead to problems getting loans and getting seats on planes and trains.

Categories
BSD/Linux Security Tech

The wonders of Let’s Encrypt and Certbot in relation to StartSSL/StartCom issues

All websites should be encrypted. Definitely don’t do anything secure over an unencrypted connection.

To support that the site has always had SSL setup. However I just discovered that the SSL certs the site uses by StartSSL have been revoked by all major browsers it appears!

A little digging for a new free SSL cert site came up with Let’s Encrypt. That in combo with Certbot is SUPER EASY to get certs and keep them up to date. All for free! I’ll probably even donate it’s so easy now!

The trick for certbot for me was to use the standalone check so I didn’t have to mess with the NGINX server’s folder security.

$ certbot certonly --standalone -d example.com -d www.example.com

Then you just point NGINX to the PEM files it creates and you’re set!

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

EASY PEASY! Now Chrome and Safari work again!

Then to renew all the certs at once you can run this

certbot renew --pre-hook "service nginx stop" --post-hook "service nginx start"
Categories
BSD/Linux DrupalRecover Security Tech

Heartbleed

So looking at XKCD you’d think ‘How could they possibly let this bug go?’ That’s so obvious:

Looking at this other blog that purports to show the code causing the issue (and I do look at various forms of computer code daily) you’d say ‘How the heck would they ever know this is a problem?’ Perhaps we shouldn’t be allowed to code in C. The fix:

The fix

The most important part of the fix was this:

/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->rrec.length)
    return 0; /* silently discard */
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0; /* silently discard per RFC 6520 sec. 4 */
pl = p;

This does two things: the first check stops zero-length heartbeats. The second check checks to make sure that the actual record length is sufficiently long. That’s it.

OK, maybe I see somewhere there a related fix they descibe. I suppose if one gets over the ‘s->s3->rrec.length’ it makes sense as long as they are doing that (I assume) pointer *p++ right too. And pl=p, that’s totally obvious!

If you look here it wasn’t looking to request lengths at all before the fix. Some QA! If the technology is to allow you to request a number of letters and you don’t test that you can get more than you should that is still sort of bad.

Thank goodness for SQL, Java, and Python! Even thank goodness for Mumps (the programming language). At least (not in Mumps) then you could make the request an object of the requested length and drop everything else.

This site was secure I found thanks to it using forward secrecy (at least since the conversion to Debian – seems like the old version of FreeBSD was unaffected as well). No idea how it was using that but phew! Since ran some SSL check and we’re an even more tight ship now!