Dot-US ccTLD Opened for DNSSEC signing, new SSL Certificate Authority model proposal
Well, kind of. In order to get your Dot-US (.US) ccTLD DS record to be added to the Dot-US zone, you need to have NeuStar as your Registrar. NeuStar is the Registry for Dot-US (and Dot-BIZ), but not the Registrar of all Dot-US domains. In my case, I have two Dot-US domains. Roysdon.us and Roysdon.Modesto.CA.US. The first is registered through GKG.net, so they are my Registrar there. GKG, nor any other Registrar other than NeuStar have officially been listed as having Dot-US DNSSEC support yet, so I have to wait. However, my "US Locality" domain, Roysdon.Modesto.CA.US, does have NeuStar as my Registrar, as it is a legacy domain, back from when Dot-US domains were where for free and allowed citizens, businesses, organizations and government agencies establish unique, memorable American identities online.
Eventually the Dot-US Registrars will get ramped up and give support to the johnny-come-lately folks who don't have US Locality domains, but the DNS infrastructure is there now.
Well, kind of (yeah, just a few of these "kind of's"). If you want to allow anyone with a little technical skill to list your entire Dot-US zone. If you don't mind them seeing every single record you have, well, then you can add DNSSEC DS records into the Dot-US zone and have a trust chain all the way from the Root, through Dot-US, to your domain. Why is this information security hole required? Well, right now Dot-US is only allowing NSEC record algorithms 3 (DSA/SHA1) and 5 (RSA/SHA1), but not NSEC3 record algorithms 6 (DSA-NSEC3-SHA1) and 7 (RSASHA1-NSEC3-SHA1). NSEC3 is important for those who wish to keep their zone data from being enumerated (listed) and therefore exposed to anyone who has just a little technical skill. The full list of DNSSEC algorithms should be supported by all Registry/Registrars so, and hopefully the lesson to be learned by other Registry/Registrars before they implement DNSSEC support for customers.
I'm confident that the Dot-US Registry, NeuStar, will address this and open up the zone to allow domain owners to submit any valid DNSSEC DS algorithm type, and I have requested they do so.
As others have said, DNS is public info, but that's not 100% true. It's mostly public info. It's sort of like the Freedom of Information Act: You have to know what to ask for to get it. You can't, normally, say, "Give me all your DNS records." A proper DNS administrator will block AXFRs (Zone Transfers) to anyone except the servers that need AXFR access for replication. As I said, if you sign your zone with DNSSEC NSEC, then all your base are belong to us [sic].
To prevent zone enumeration via "NSEC walking" you want to sign your zone with NSEC3. However, you cannot generate NSEC DS records from NSEC3 keys (and visa-versa). So if you want to submit your DS record to NeuStar, you need to sign with NSEC, which means you need to expose all your records to being listed.
For now, I came up with a work-around: Sign my Roysdon.Modesto.CA.US zone with NSEC so I could submit my NSEC DS record to NeuStar, but have no records in it except the bare-minimum requirements (SOA, NS, MX), and the delegation of a child domain via NS & DS records. The child domain, home.roysdon.modesto.ca.us, is signed with NSEC3, and its NSEC3 DS record can in the parent NSEC-signed zone without issue. As home.roysdon.modesto.ca.us is NSEC3-signed, it is immune to NSEC walking, and my records secure.
It's not like my NSEC3 zones have some top-secret records, but I do put a lot of information in there. HINFO records are a nice way to store the Hardware and OS, LOC records for storing LAT/LON coordinates (which can be dynamically updated and obtained from and cell phones using GPS or Wifi APs can be used to cross-reference approximate LAT/LON coordinates), RP records for who owns a system, TXT records for whatever you might want to store (try and find out what Ox.roysdon.org, Eagle.roysdon.net, Lion.roysdon.us have to say in their TXT records), but you could store Serial/Asset numbers in them, WAN Circuit IDs, even vendor support contracts and numbers. Not to mention just a list of all the hosts themselves - why do you need to know how many systems I have? It's nunya.
I also store SSHFP records, which allow me to SSH to one of my hosts from a new host and not yet have the SSH key. By using SSHFP records in a DNSSEC-signed zone, I know that the SSHFP record wasn't tampered with in the DNS reply, and I can verify that the SSH key that my server is sending wasn't tamped with by verification of the SSH Fingerprint record.
I think a revamp of the SSL Certificate Authority (CA) model is order now as well. SSL CA digests should be stored in DNS for the zones of which they are to issue Certificates. SSL CAs should become hierarchical, the same as the DNSSEC trust model is. A browser with zero Root CAs installed, and only the Root DNSSEC Trust Anchor. From there, it could bootstrap the entire CA architecture for each record needed for SSL requests. For instance, use DNS to find out the NS of roysdon.modesto.ca.us and be able to verify each reply from the DNS Root down to my NS servers (which can be done now, that infrastructure is there and all records are DNSSEC-signed), and then request a "CA" record and "CAFP" fingerprint record from the zone. My proposed "CA" record would be the name of the Certificate Authority, and the "CAFP" would be fingerprint digest such that after the CA Certificate was downloaded, the CAFP would verify that it was the correct CA Cert.
The great thing with this model is that a domain owner would have the ability to chose how they want to host their domain's CA. They could do it internally or use a third-party CA, either because they didn't want to host the infrastructure for a CA themselves, or because they wanted some sort of Extended Verification (EV) done by the CA. Verisign, et al. would not like my plan, as they'd only make money for folks not hosting their own CA themselves, or where free CA's could not be found. Invalid self-signed SSL certificates would become a thing of the past. DNS hijacking and spoofing won't work as DNSSEC will block it, and potential rogue CA's like Etisalat (thanks to Verizon/GTE) and CNNIC won't be able to create their own Intermediate CAs for just any zone they want and monitor traffic.
Not to re-invent the wheel completely, it looks like RFC4398 which specifies CERT records may be able to be used for not just CA's but also GPG keys. Whatever the RR is matters not to me, so long as it puts the control of the SSL Cert into the hands of the domain owner (or any cert for that matter, as GPG keys would be nice as well).
By the way, even if you remove Root CA's you don't trust in Windows, Microsoft will add them back for you, unless you disable this feature. I don't see any need to trust CNNIC, so I've removed this Root CA from my browsers, but am still debating removing Verizon/GTE's Root CA.
Update as of July 18, 2010:
Sign-up with Clearwire, sign-up for Spam!
In April I decided to try Clearwire to see if it was a viable solution for my internet. Shortly after, I started receiving spam thanks to them, and it's easy to prove.
Dot-ORG TLD Opened for DNSSEC Signing
The online world just became a little more secure yesterday. The dot-ORG (.org) top-level domain (TLD) just opened up the ability for the owner of a .ORG domain to include their zone's DNS Security Extension (DNSSEC) Delegated Signer (DS) key.
McAfee DAT 5958 problems with Windows XP SP3
McAfee pushed out DAT 5958 which mis-detects SVCHOST.EXE as being infected on WinXP hosts with SP3. For many machines this breaks networking and/or other services and may put the server in a endless rebooting loop problem.
The fix is to apply this EXTRA.DAT file attached to McAfee KB68780 which will suppress this mis-detection that 5958 contains, and then put back SVCHOST.EXE from a known-good system.
Not updating your AntiVirus is misinformation. You need to update, but you need to apply this EXTRA.DAT as a manual fix in addition to 5958.
To deploy EXTRA.DAT on machines with VirusScan Enterprise 8.5i and later, an Access Protection feature must be temporarily disabled before proceeding. Do this by accessing the VirusScan Console, Access Protection, and unchecking the Prevent McAfee service from being stopped option so that you can then disable the McShield service and deploy EXTRA.DAT. Be sure to turn back on the Prevent McAfee service from being stopped when done.
Free SSL Certificates
If you have your own domain, like roysdon.net, you may at some point want to be able to login to a webpage, receive and send email, transfer files with ftp, and even connect to your own network with a virtual private network, or vpn. You'll want to do this securely so you know no one is watching your login authentication or data that you're transmitting.
Secure Sockets Layer, or SSL, is the means to accomplish this. Then you can log in from a PC and trust that your authentication and data isn't going to be intercepted or modified on the way from the PC to the server.
In order to use SSL you need at least one SSL certificate. While you can create an SSL certificate and self-sign it, the rest of the world will not trust it, and it'll cause error messages about being untrusted.
The important step here to have the rest of the world trust your certificate is to have your SSL certificate signed by a Root Certificate Authority, or Root CA. Root CA's normally charge for this service, but you can get a CA-signed SSL certificate for free.
Serial port redirection to console in Linux
There are times when keyboard and video monitor access (KVM) is not always accessible or scalable. Serial port redirection to console is a way to be able to access hosts before booting the OS in Linux.
I will discuss 3 different steps that are needed to accomplish this in Linux.
Website Gotchas 101
So you want to make the leap on to the interwebs, I mean webtubes. You want something bigger than your FaceSpace, err, MyBook page. You know those social-thing-a-ma-bobs, right? But you don't have big enough pipes coming to your house? What do you do?
You can pay someone like Hurricane Electric $1/month to host it (or GoDaddy, GKG.net, and hundreds if not thousands of others out there). But how do you choose? Here's how:
Following Fedora Package releases for RHEL/CentOS admins
There comes times where you need a feature not yet in the version of a Package that RedHat has released yet for Enterprise Linux (RHEL, or just EL). BIND is a perfect example of this.
RedHat still ships BIND 9.3 (with back-ported bug-fixes for security), but for full DNSSEC support you want Fedora's BIND 9.6.
My goal: don't go totally off the beaten path and compile from source from the BIND upstream, don't become a package maintainer, don't trust a non-RedHat source, but still don't want to even have to think much about any of these non-Official Packages I'm using until updates come out. Fast and proven aren't always compatible, so at least "tested" from RedHat/Fedora will work for me.
Wordpress Update 2.8.5
I just wanted to give a shout out to Wordpress, my blogging platform. I've used it since I switched from MovableType whenever they went to a pay model, plus I wanted a completely OSS solution that I could use commercially.
I love that I can upgrade my Wordpress version with the click of a link on my Dashboard.
In fact, it takes me longer to back up my Wordpress install than to update it, just because I need to type in my mysql password:
Building BIND 9.6 on RHEL5 / CentOS5 for DNSSEC NSEC3 support
For those of us with the need for DNSSEC NSEC3 support (required for .GOV, .ORG and others) on RHEL5 / CentOS5, official support isn't coming until RHEL6 (RH BugID 504052). For now, though, we can use the source RPM from Fedora 11 (now Fedora 12) to compile it ourselves.
Install rpmbuild and other dependencies:
yum -y install make gcc rpm-build libtool autoconf openssl-devel libcap-devel libidn-devel libxml2-devel openldap-devel postgresql-devel sqlite-devel mysql-devel krb5-devel xmlto
Download the latest F11 bind and dnssec-conf src.rpm:
cd /usr/src/redhat/SRPMS
wget -c ftp://mirrors.kernel.org/pub/fedora/updates/11/SRPMS/bind-9.6.*.src.rpm
wget -c ftp://mirrors.kernel.org/pub/fedora/updates/11/SRPMS/dnssec-conf-*.src.rpm
Update: F12 has been released with the latest bind and dnssec-conf src.rpm:
cd /usr/src/redhat/SRPMS
wget -c ftp://mirrors.kernel.org/pub/fedora/updates/12/SRPMS/bind-9.6.*.src.rpm
wget -c ftp://mirrors.kernel.org/pub/fedora/releases/12/Fedora/source/SRPMS/dnssec-conf-*.src.rpm
Now install the SRPMs (the trick here is --nomd5 to stop signature verification which will fail due to Fedora's new sha1sum version in RPM):
rpm -ivh --nomd5 bind-9.6.*.src.rpm dnssec-conf-*.src.rpm
Build the RPMs:
cd /usr/src/redhat/SPECS
rpmbuild -ba ./bind.spec
The built bind RPM is now in /usr/src/redhat/RPMS/i386/ or /usr/src/redhat/RPMS/x86_64/ depending on your Arch.
rpmbuild --ba ./dnssec-conf.spec
The built dnssec-conf RPM is now in /usr/src/redhat/RPMS/noarch/
To install bind and dnssec-conf, you need curl and python-dns*(requires EPEL):
yum -y install curl python-dns
Then:
cd /usr/src/redhat/RPMS/*86*
rpm -Uvh bind-9.6.*.rpm bind-chroot-9.6.*.rpm bind-utils-9.6.*.rpm bind-libs-9.6.*.rpm ../noarch/dnssec-conf-1.21-*.noarch.rpm
A newer dnssec-conf is available via EPEL that is more up to date (ITAR, etc.) than the current F11 SRPM (F12 is current), so update it from there if this is allowed by your policy:
yum -y update dnssec-conf
Now you need to subscribe to Fedora bind updates so you can repeat as bug fixes are released. (I've written a detailed post describing how to do this).
--
Update Jun 1, 2010: RedHat has published a BIND 9.7 tech preview for RHEL5.6 per my request:
http://people.redhat.com/atkac/bind/5.6-test/.
Securing your PC on a budget
There are many different options to help you secure your PC. Good password protection, software protection, and network/dns protection.
There are two important things you can do to secure your computer, no matter if you run on Windows, Mac, Linux, *BSD, or whatever.
SSH Public Keys & Fingerprints via DNSSEC
Highlevel:
When you SSH to a host/server, the host/server sends its Public Key, much the same as an SSL connection allows you to do with a web-based https connection. This allows you to encrypt data from your client and send it to the host/server which has the Private Key to decrypt it.
With SSL/https we have Certificate Authorities (CAs) that do some sort of verification and then sign SSL certs. Our web browsers (Internet Explorer, Firefox, Opera, Safari, etc.) come with a list of CA Roots. This allows us to verify without going external to our clients that a Public Key is legit, as it has been signed by a pre-trusted CA Root.
DNSSEC technical details
I originally posted a more simplistic overview of DNSSEC that is a good first read if you're new to the subject.
I'm going to borrow and re-work a little content I made from a future post about SSHFP but that is relevant to DNSSEC.
With SSL/https we have Certificate Authorities (CAs) that do some sort of verification and then sign SSL certs. Our web browsers (Internet Explorer, Firefox, Opera, Safari, etc.) come with a list of CA Roots. This allows us to verify without going external to our clients that a Public Key is legit, as it has been signed by a pre-trusted CA Root.
...
DNS suffers from the same MitM attack problem as anything else. However, we can sign DNS with DNSSEC and we already have trusted equivalents of CA Roots, in the form of the DLV.isc.org system, and eventually with DNSSEC signed DNS roots.
DNSSEC is not the same as CA roots, but it is close in some ways.
Why you want Google Voice
Moments ago this conversation took place via SMS to my Google Voice number:
(408) 642-XXXX: My bad bt wat u doen 2:47 PM
Me: Who is this? 3:16 PM
(408) 642-XXXX: Wh0 iS dIS 3:16 PM
Me: Yes, that's what I asked. Who is this? 3:17 PM
(408) 642-XXXX: N0 N0 WH0 iS dISz 3:18 PM
Securing the internet with DNSSEC, one DNS query at a time
Dan Kaminski found one design flaw with the majority of DNS servers as well as exactly how to exploit it in a repeatable fashion. There are many other problems with DNS attacks that would be solved with DNSSEC.
Just what is DNS?
Secure email and files
There are plenty of legitimate reasons to use encryption for emails. Some reasons for using encryption is with overseas communications to relatives or business partners, or even local communication but of a highly sensitive or confidential nature, such as network configuration files, Visio network diagrams, system passwords, etc. Perhaps you want to email your paystub PDF from your work email to your personal email, that'd be the perfect candidate for encryption.
How secure is your network?
Conficker [?] is set to start its new "upgrade" right now, starting in the GMT timezone and rolling around the world as
End users can do quick tests
