One of the comments in the post this links to claims that it's an urban legend and I think that maybe correct. I remember those times and was an avid follower. Even the earliest Apollo missions had a "go round" bailout if they aborted a landing. Not sure you would call that a "sling shot" but they did know full well the trajectories.
This is an old issue and people have done it better for a long time. The vendors (MS included) CHOSE to use half hearted, stupid, and short sighted solution. I saw proposal papers over a decade ago at the ISOC (Internet Society) NDSS conference:
Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
Andrea Rierra and Joan Boerrell
http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/riera.pdf
Start there and get serious.
Right. This is why you root your phone. It's to de-crappify it. You take that crap off. I love Cyanogen Mod! Shouts to Cyanogen and congrats on the new job!
Vendors of phones and network providers refuse to accept the very concept that you own your bloody phone and have a right to do with it what you want. It's the Bell system from the '60's and earlier (pre AT&T divestiture) all over again. They get to tell you what you can do with your property and you will smile and you will like it.
Apple is even worse. They will dictate your entire experience and, if they are not happy with an applications which does not meet their agenda, politically or socially, they will cut them off. They take dictatorship and crapware to a whole new realm of reality. Oh well...
I opt for freedom.
Several of the vendors have gotten on the clue train. HTC is there. Samsung hired Cyanogen and is opening THEIR bootroms. Motorola (soon to be Google, maybe) fought it but threw in the towel and announced they would unlock their boot roms. They ARE getting it. The VENDORS are getting it. The carriers are NOT as yet. The clue train has not arrived for them. We need to teach them and we need to teach them a painful lesson. If it costs them money to kept their hands on our short and curlies, eventually they will get a clue and release their grip. AT&T sucks. They want to extend their control as much for the money as to dominate you and dictate to you where you have no option. That's mind control. That's corporate 1984. That's what we call a "monopoly" and that's what has to be prevented.
ITMT... It is established law that you have a right to root your phones (DMCA exemption as determined by the library of congress...)
DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
Could you address those?
Yeah, I'll give it a shot.
First off "the right solution to the TLS security problem" is a problem. "TLS security" is not a single (the) problem but a multifaceted problem. DNSsec addresses (doesn't totally solve - none do - but does address) one of those facets (tying the cert to the domain owner). The fact that a malicious state level actor controls both DNS (and their ccTLD DNSsec signing) and the certificate authorities just leaves you in almost the same spot except I would argue that DNSsec has a leg up there. Not perfect, but better and more verifiable.
Controlling the CA, they can spoof a MITM certificate claiming to be you. Now, you have to validate all your certificates from an outside point of view. Or they issue the certificate and key to you (bad BAD practice done by many CAs for TLS E-Mail certs - they should NEVER have possession of the private key) and you will never be able to tell if they are abusing your cert or not. That's bad. That's real bad.
With DNSsec, you give them your public key signing key (ksk). They either properly sign it and publish it or they don't. You can verify this in the public DNS (plenty of public query servers and looking glasses and historical sites for DNS - aot site certs where you're on you own). You use your private ksk to that public key to sign your zone signing public keys (zsk) and you publish that public key yourself, which you can then also verify. Then you sign your records with the private key of your zone signing key. All of this should be confirmable from the public DNS but, in the case of a malicious state actor, you may still have to confirm it from an outside view (a looking glass or secure remote server) but you only need to verify that THEY properly published YOUR ksk public key and that they are not blocking DNSsec. You never give them your private key (never underestimate the power of what Bruce Schneier calls "rubber hose cryptography" - they beat the bejesus out of you till you give them the bloody key).
Is it bullet proof? In the face of a malicious state actor, nothing is bullet proof. We can only try to make it tougher for them.
And how is this (which requires to pay money to a CA) any better than certs with the key fingerprints / signatures in DNSsec (which is free)?
Yeah, especially when you have clowns like OpenDNS saying they won't support, or even pass through, DNSsec because they like DNS Curve better. The two standards (and I say that loosely because DNS Curve is NOT a standard and no where close) solve different problem sets but OpenDNS is too dense to realize that.
Well... The fact that it became known does not speak much for their secrecy, and secrecy in this regard is a very relative term, even if the group ever intended it to be a "secret society Illuminate". Sometimes (and I've seen it happen all too often) someone accuses people of discussing things "in secret" only because they weren't a member and the membership signup was not obvious to a 3 year old. Without knowing more about the specific list and group, it is impossible to judge their motives based on an unsubstantiated claim of a "secret mailing list".
I've been a member of "closed" mailing lists before and continue to be to this day. It's generally a question of someone vouching for you. Example... In the dark early days of the Internet and the Robert Morris Worm incident, we had two parallel security lists. To get on the Zardoz list, you merely had to sign up. To get on the ISIS list, you had to have some vouch for you in the "bang path" (uucp notation) between you and them.
More recently, certain mailing lists, such as the recently defunct VendorSec mailing list,. required a discussion amongst the members for you to join. Especially, in security circles, there's a matter of trust and reputation and the very real problems of disruptors , some of whom are "state sponsored" (the government really doesn't like it when you can protect your privacy and your security - you should depend on them for that, right? They long for their good old days of ITAR). Sometimes (SERIOUSLY) some of those lists are there discussing things of a serious enough nature that we don't want the "bad guys" to have a heads up. Some of us have to collaborate in a trusted manner somehow and, yes, we're going to get accused of "operating in secret". But it's just a matter of knowing who you are communicating with and can trust them. This doesn't sound like that kinda list but I would love to know what list it was. There are probably a dozen or more lists on the net right now discussing this very issue, probably including one or more IETF lists. It's generally not a "cabal" and I've never found it hard to join one if you have the reputation to be trusted.
Domain Validation (DV) certs are not the same as OV, Organizational Validation, or EV, Extended Validation, certs. Web SSL certs are OV or EV. DV certs are intended to validate that the FQDN is valid (i.e. correctly owned by the domain). This is the job that DNSsec is meant to address in many ways. There's already been public discussion on some of the crypto forums such as mozilla-crypto (ok, for some value of "public" - but it's not a closed list). The DNSsec crowd have asked about putting certificate signatures in DNSsec and the entrenched CA crowd got all up and in arms and huffy about it. But DV certs would just tie the certs to the domain owners, and that's all, which is exactly what can be done in DNSsec. And, yes, we all know, the domain could be faked but that's not the point. The point is to tie a certificate back to the domain owner or not. The OV/EV certs are what validate the organization claiming to own the domain/FQDN. The CA crowd doesn't like the fact that DNSsec can do for free what they can charge money for. DNSsec puts the power totally in the hands of the domain owners (where it bloody well belongs). Now if we could just get certain bloody registrars, like Network Solutions, to let us register our key signing keys, we could get on with things. The root zone (.) is signed. The
Looks like those include the zBoost units. I have one for Sprint. Love it. I can see the signal improvement powering up the unit. I got mine from SmartHome and can highly recommend them. Just be sure to get the right unit for your band.
Yeah, these are the ones available from SmartHome. I agree! They work great.
If what you're after is a cell phone extender, then I can highly recommend the Wireless Extender Cell Phone Signal Booster from SmartHome. They are NOT cheap (> $200 single band. >300 for the dual band unit). But, after laying my money down and running the wireless antenna up into my attic with the repeater system and antenna down in the basement, I can honestly say, I've got a better cell phone signal in my basement than upstairs on the main floor or even the second floor. Be mindful that you get the right unit for your band / service. I got one that works with Sprint and I love it. Works with my 3G data network and data card from them as well (as would be expected - it's just cellular). Comes with enough cable to span two stories up into an attic from a basement.
Works with all 800 MHz cellular phone systems (Verizon)
http://www.smarthome.com/9625C/Wireless-Extender-zBoost-Cell-Phone-Signal-Booster-for-CEL-Phones-YX500-CEL/p.aspx
Works with all 1900 MHz PCS-based phone systems (Sprint, NexTel)
http://www.smarthome.com/9625/Cell-Phone-Signal-Booster-YX500-PCS/p.aspx
Works with both 1900 MHz PCS-based phones AND 800 MHz cell-based phones
http://www.smarthome.com/9631/Wireless-Extender-zBoost-Home-Office-Cell-Phone-Signal-Booster-Unit/p.aspx
I'm the author of a number of patches to a number of OSS projects, mostly security related. So, I would love to know what this "authentication module" is. Sounds like it might be PAM or maybe Apache related?
Over the last year and half or so, a major OSS routing package, Quagga, was largely on "auto pilot". The maintainer was not being responsive and outstanding patches were piling up and releases were over due. This project was, in and of itself a fork of an earlier project, Zebra, that had gone stale and been largely abandoned by its developers. Several months ago he popped up back out of the woodwork explaining that his job (that supported his work on this project) had been overwhelming and he had gotten way behind in things. Since then, most of the patches that had piled up in his queue have been integrated and several releases have cycled out and the project is now approaching it's first 1.0 release candidate. That project is alive and active once again but, before he returned some people were already starting to talk of yet another fork.
It happens and it can take time. If the project has a list, post to it and seek out some of the past contributors. Don't give up on him, he may be just extremely busy putting food on the table. The entire CentOS distribution was threatened by the absence of their lead (covered in other SlashDot articles). He showed up after all the publicity.
On the other hand, some projects deserve to die. A couple of VPN projects and crypto projects have been abandoned by their authors and maintainers and don't deserve to be resurrected (bugs, security holes, etc) even though they still had followers. Doesn't sound to be the case here but it's hard to tell without knowing what it is.
Perhaps you should rethink that mistake and create a real "master" and make them "slaves". The system was designed this way for a reason. It baffles me why people do things this this way.
A server behind a firewall does not imply a server on a private network. You can have firewalls in front of a DMZ on a public address providing services. Firewalls are used for much more than merely "private networks". Those are two orthogonal issues.
OTOH... A master on a private network providing zone feeds to slaves on various other networks (firewalled or not) on public addresses would be a very good idea.
This isn't Windows...
# yum -y update named\* && service named restart
(Not sure if yum [or apt] would restart named and NOT willing to take the chance.)
"Beware of programmers carrying screwdrivers." -- Chip Salzenberg
