Tech – Lumos 🏳️‍⚧️

2015-10-14

Now secured with DNSSEC

In the last few days, all my web services have been secured with DNSSEC. I have used DNSPod for some time and am pretty satisfied with their service, but after some incidents of failing to resolve for foreign places, I decided to change my DNS service. So my DNS service has been changed, and also secured with DNSSEC.

DNSSEC is a chain of trust service that authorization each DNS reply using asymmetric encryption. It starts from the top-level CA, which is “.”, and then some gTLD, like “org.”, and then the register’s domain. It’s a signing only method, so the DNS request is not encrypted and can be cached. The weakest point is that your domain registrar has total control over the DNSSEC key so that if your domain registrar wanted to change it to another thing, it would be done. Also, the encrypted key of “.” and “org.” is both 1024 bit RSA, so there may be some possibility to break it using a really big supercomputer within expire time. (there is about 1.47% possibility that you can break a 1024bit RSA key using Tianhe-2 under six month)

It’s a good way to prevent DNS poisoning. With DNSSEC, the most respectable mail service(Google) will not be fooled by easy tricks to send the email to some MIMA server. Also, if the client’s DNS service is secured under DNSSEC, the client will not be fooled to another site.
However, there is little ISP that does the right DNSSEC check inside China. One famous DNS provider inside china, 114DNS, has exactly zero aware of DNSSEC. And if the DNS record is signed with the wrong key, the 114DNS will not care and just return the malicious result.
So I set up three DNS servers to do the right DNSSEC check. One for my personal network(mail/VPCC/wiki/gitlab/backup/LDAP/WebDAV…) and another for my personal VPN. The two DNS servers using another DNS server as a cache. Now the weakest spot is that before I start my VPN, the DNS is poisoned. However, as my VPN is secured using another set of RSA keys, and I never visit anywhere without my VPN on, it should be fine.

With DNSSEC, I can now have my keys published using DNS. Now my GPG key for [email protected] can be auto-fetched if the DNS search is enabled. The weak point is that the DNS search function is not capable of verifying DNSSEC at peer but relies on the remote resolver. RFC4035 seems to be suggesting any client with the ability to check DNSSEC to check DNSSEC by itself. I believe GnuPG is a client that has the ability to check DNSSEC and should have checked DNSSEC. Without that function, anyone can just modify the UDP package between the resolver and the client to give the client any key the attacker likes. A temporary solution would be setting up a DNSSEC capable resolver at the localhost and dig from 127.0.0.1:53.

Whatever, having it is better than having nothing. But still, if you want to send me encrypted emails, see about page on this blog and using keys there, or make sure you are doing DNSSEC check at localhost…

2014-01-23

Now lab to 6.5

After altering some files in gitlab, the upgrade process becomes not an easy and happy job. Every new version comes out, dozens of files need to merge manually in order to upgrade gitlab successfully. So, after hours of mental struggle, I finally decide to upgrade it. The process is not as terrible as I thought it would be. But still, DOZENS of files to edit……

And now the update process has been finished. All things seem to be good. If anything went south, please email me~

2013-09-24

SQL’s not end

Today, in a distributed cloud environment, there is no good DB that can have both ACID and SQL support, at the same time keep the performance scale. So, there is NoSQL.

NoSQL means Not Only SQL. It does not means NO SQL. MongoDB-like applications have set up a bad example for its followers. A NoSQL DBMS might not use SQL as its base query language, but it at least should support SQL as a higher layer query language, just like what FoundationDB tries to do. Of course, the problem is ACID with the flexibility of SQL language, which is a rather difficult problem for a sharding DB, who becomes more and more common since cloud computing is conquering the server world. SQL language itself is not difficult to carry out, ACID with the ability to support complex SQL is.

But ACID is a must-have feature in many apps, not only bankers needs ACID, all app developer who wants to make a robust app must have transaction as one of their basic tools. No one can accept an app if it only acts normally when the user is lucky. Those who want to throw away ACID will only find they are implementing their own ACID solutions later.

There are many ways to overcome ACID implement problem. In the cloud, locking is an unacceptable way, unless there is some way to lock and sync at a very small, accurate level, which is not an easy job for 100+ sharding servers. Log and check(MVCC) is another way, which is easier than locks, and implemented in many DB solutions.

If ACID is possible in a cloud, SQL will be, too. But it may exist as a layer on an ACID system based on some simpler API. Whatever, SQL will not be ended by NoSQL and cloud, it will still be used in many places for whoever wants to keep data update easy(or even possible). Maybe one day there will be only copied and not reference in DB world, but I think the day has not come yet.

2013-09-21

DoS defense

Now, this site is free from small DoS attack. I use iptables, evasive, and some other techs to protect this site. Iptables will kill most DoS links after it reached some condition. I think any DoS attacker with only one IP can’t flood my site now. Cheers!

2013-09-21

New server for new app

Well, a new Linode server with LUKS has been build to support this website and a branch of new applications. Build a LUKS encrypted system on a VPS is an exciting experience. However, sometimes, it seems stupid to do so. Since an admin who records every keystroke will easily record the password for LUKS. But my password is not for Linode, but for its hardware maintainer. I do not think Linode will record custom’s keystroke in their Lish console, at least not publicly. If they record it privately, it will only be available to a little part of their organization. So that if a disgraceful programmer wanted to record every file created in all Linode systems, he/she would not get my password to do it, though I’m not sure.

Of course, everyone who wants to get the LUKS key can do it by analyzing the memory. But it needs time and attention. So, hopefully, if people can put very sensitive like customers’ credit card numbers on Linode server without any encrypt, perhaps I can put my diary on it too.