You can create a virtual SSID in an isolated VLAN. Nodes that attach to that SSID would use an SSL VPN to connect to a single dual-homed device providing the SSL VPN connection. No need for WEP/encryption at all if you do that.
If someone is not technical enough to know how to do that, I would not give them WEP-only gear as it is just a setup for trouble.
Incorrect. Firefox, Thunderbird (you can use Startcom free SSL certs for your POP3/IMAP/SMTP servers too), IE as of a Sept, 2009 (?) root certificate update, Chrome, Safari, and Opera all work just fine. They don't list Opera, but I just tested on my own sites, it works just fine. With a little OpenSSL work, you can even use Startcom SSL certs with Cisco SSL-based VPNs.
If the interference is 2.4-based 802.11b/g, you'll be able to find it. Won't help you any with 802.11n, which may just be your problem. Might be someone's 2.4GHz phone. Might be someone who microwaves a bunch of stuff. 2.4GHz is a swap free-for-all.
If your.ORG domain Registrar is not listed as providing DNSSEC support, transfer your domain to GoDaddy or one of the other 12.ORG Registrars with DNSSEC support.
Then generate your keys, sign your zone, and provide your Registrar your DS key. Anyone using a DNS server with DNSSEC enabled and ITAR keys will have the.ORG key and follow the chain to your domain. Anyone using a number of DLVs will also find the.ORG key.
Full support will work once the Root zone is signed, and then the ITAR will no longer be needed, and the DLVs will not be needed at all as more TLDs become signed.
If you're totally green to DNSSEC and didn't get the alphabet soup, you'll need to do some reading.
There is a Firefox add-on, DNSSEC Validator, which appears to work for the pir.org zone, as well as my own roysdon.net zone. Both are DNSSEC signed, although my roysdon.net is found in the DLV.
You can point the tool to use Comcast's DNSSEC trial resolver which is DLV-enabled at 68.87.68.170. You can trial Comcast's DNSSEC trial resolved which does not have DLV support at 68.87.64.154 and rely only on the Root signature and previously published ccTLDs like.SE.
pir.org is an example of a zone which you can verify just by having the root zone's key. The root signs.ORG, and.ORG has signed pir.org. As opposed to DLV-enabled zones, like mine, which rely on dlv.isc.org until.NET is signed. Well, also until Registrars add a way so that.ORG owners can sign their zones.
No, nor while it have ipv6 records. Why would they really care about tech? The real motive is profit. No profit in slowing down dns queries with DNSSEC or potential problems right now with broken ipv6 transit or clients.
Speaking of SSH and the like, the solution to this sort of madness is simple.
Arrange to have someone purchase a drive ahead of time for you in the destination country. Dd your drive to a drive that you leave in a secure location at home. Rsync your data over ssh to the remote PC with your drive before you leave. Securely wipe your HDD and use your computer manufacturer's restore DVD to reinstall. Cross boarder, if laptop is seized, buy new laptop at destination. Pop drive with data in laptop (new or otherwise) and continue on.
One return, do the same thing with changed data (rsync diff over ssh to your home PC) and repeat secure wiping of HDD and restore DVD.
A little hassle, but no way except you being framed could anything ever be found, and all your data is safe. Worst case you are out a laptop or two while they are searched.
This is a scam just like the many stratosphere airship scam companies that have been around in the last decade or so. They have no working product. They have no customers. It's all just a scam.
I don't get why you wouldn't have dual-redundant power supplies on all devices (routers, switches, servers), one on transfer switch A and the other on transfer switch B, each connecting to different backup power sources. Further, these should be tested on a regular basis (at least monthly). Test transfer switch A on the 1st, and transfer switch B on the 15th.
Seems like a design flaw here and/or someone was just being cheap.
Meh, when done right, it just looks like a long ssl and/or vpn tunnel session.
You really cannot do much to filter/firewall this sort of bypass for the technical user. Unless you allow whitelist-only access to https/ssl sites and/or force corporate-only machine access with corporate-installed SSL CAs that decrypt SSL traffic and re-encrypted (putting the corporate proxy as a man-in-the-middle) you have no way to stop this.
The real trick is blocking all "leaking" dns and apps. Socks leaks badly, as does flash, java and many other plugins. Just firewalling all outbound traffic except your tunnel works, but will require a dedicated machine.
http to a remote proxy over openvpn (ssl) is a bit more efficient than socks over ssh and clearly better than socks over ssh over ssl.
As I maintain my own DNS servers and such, I was curious how this worked. Here's what I learned with 15 minutes of research:
My first stop was to see the root.zone and I looked for these new TLDs, curious to see how they would show up in a Latin-based zone file. Ah, I spotted these odd XN-- zones and then knew what to dig into more.
Take for instance (I pasted a Unicode domain, but Slashcode won't show it) which is handled by ns[1-3].dotmasr.eg.:
If you look in the root.zone file, you will see that the ASCII/Latin version of this zone is really XN--WGBH1C.: XN--WGBH1C. NS NS1.DOTMASR.EG. XN--WGBH1C. NS NS2.DOTMASR.EG. XN--WGBH1C. NS NS3.DOTMASR.EG.
I hate to see Novell die (I was a CNA way back in the day, and learned NetWare 3.x in high school), but I think it'd be for the best interest of FOSS due to their taintedness with Microsoft.
Here's what I think should occur: RedHat should set up a third-party company that they own. That company should buy Novell. That company should sell all non-tainted assets to RedHat.
Then what is left are the tainted bits the third-party is holding. Let it just die or shut down or whatever it is that you can do with a corporation to put it out of its misery.
I second this advice. I don't care about other services, so denyhosts is good enough for me. I like the shared database nature, much like spam databases.
Implement one-time passwords for new users. One time in, push public key, password no longer works. Use pub/priv keys only. Then every failed password auth can be set to fail after 1 attempt, and you can spread the goodness with denyhosts.
Just saw an add for $29.99/month Comcast internet + cable (probably just broadcast, dunno) for 1 year. I think I cancelled my service too soon though (just last month). How long do I have to be "not a customer" to be a "new customer" ? Hmm, and IPv6 native service isn't that far away either. I'll probably switch back.
SSL CA authority needs to be tied to domain hierarchy.
This sort of domain-based-CA's should be able to be installed via DNS and DNSSEC should be continue to be rolled out, all the way to the client (browsers should have methods to verify root DNSSEC, and follow the chain).
With SSL based on domain hierarchy, you need to know only the root DNS server's DNSSEC key. Everything else flows down from that.
Then CNNIC would only control.CN. The US Gov would theoretically only control.US,.GOV,.EDU..COM,.NET,.ORG should be run by (as much as I hate to say it) the UN.
I already put SSH key fingerprints in my DNS and verify with DNSSEC-enabled openssh/bind-resolvers. SSL and/or SSL fingerprints could easily be done, if not just the entire CA public key.
Yes, at which time they could tell closed-source clients to install open-source plugins or open-source and/or more-friendly (Theora-supporting) browsers.
Or someone comes up with a license-free, plugin free solution for those closed-source clients like HTML5 Theora video codec for Silverlight. Wait, someone has done that, and they'll be releasing it as OSS soon. That solves newer IE clients, older IE clients can be told to upgrade anyway, and Safari users can be told to switch browsers because Apple is clueless (or someone will write a solution such as the Silverlight player for Theora but to work with Gecko/Safari).
Buy a cheap raid system and have an offline disk backup system.
I doubt it very much. If the video is good enough for my purposes today, it will be good enough tomorrow.
Suit yourself, you just want to argue. I'm done.
Factory-pressed CDs have superior longevity to any storage technology currently available to the consumer.
Loading 1000s of CDs ripped to FLAC and re-encoded to MP3s takes me only the transfer time limited to my phone (limited to USB2 or whatever the phone supports). How long does it take to do it if you have them only stored in CD format and have to re-rip them? I can have multiple quality levels of MP3s as well for devices that doesn't sort as much (like my kids' cheaper cell phones which support smaller microSD cards). I can run batch jobs to re-encode these without any human intervention. Your method costs hundreds of human hours of intervention flipping CDs (again) for which I've already done.
Again, you just want to argue, you've no clue what you're talking about. Stating two facts about disks failing and CDs lasting longer doesn't discount what I've said as accurate. I'll only ever lose more than 1-2 days of new data at most, because I've RAID systems in place and 3 offline backup systems that I rotate through (plus two off-site on-line backups). I'll never have to re-encode my CDs because I have 100% perfect double-verified FLAC versions.
Stating an uninformed opinion about encoding quality of today being find for tomorrow doesn't discount what I said about keeping originals. "640k of memory is enough for anyone." Yup. Bandwidth/disk gets cheaper and cheaper, for instance, my first MP3 player held 32mb, so I could just hold a CD if I encoded very lossy, but then I had to re-rip when I got a few hundred mb MP3 player... twice was enough, never again, flac saves the day and I've never ripped a CD a second time. Now I use 256kb/s vbr encoding, but I've changed at least 3 different times for my MP3s since I went to FLAC, and twice for my Oggs. Even Youtube encodes at least 2-3 times (SD, and different HD levels).
Disk is cheap. Not storing your original recording doesn't make sense, even with sticking with just Ogg Theora / OSS methods.
Ogg Theora will continue to evolve and improve. Without a doubt you will want to re-encode to take advantage of these improvements.
I crossed that logic bridge a long time ago with my CD collection. I just rip once to FLAC, and re-encode for whatever I need (usually just Ogg Vorbis, but sometimes, like on cell phones, you don't have support, so you want to re-encode with the best fidelity possible, and re-encoding from another compressed format is always more lossy than from flac/source).
From my point of view, if I'm a content provider and I don't want to lose eyeballs, I'm going to encode and support both.
Give the end user the support for all 4 of the different options (OGV native, H.264 native, H.264 via flash, or direct download for playback with non-plugin) and lose no eyeballs. To me, that's the right way to go.
Slashdot Mirror
You can create a virtual SSID in an isolated VLAN. Nodes that attach to that SSID would use an SSL VPN to connect to a single dual-homed device providing the SSL VPN connection. No need for WEP/encryption at all if you do that.
If someone is not technical enough to know how to do that, I would not give them WEP-only gear as it is just a setup for trouble.
Oops, actually Opera does error out by default, not having StartCom's root CA.
Incorrect. Firefox, Thunderbird (you can use Startcom free SSL certs for your POP3/IMAP/SMTP servers too), IE as of a Sept, 2009 (?) root certificate update, Chrome, Safari, and Opera all work just fine. They don't list Opera, but I just tested on my own sites, it works just fine. With a little OpenSSL work, you can even use Startcom SSL certs with Cisco SSL-based VPNs.
http://cert.startcom.org/
There is no reason to ever have a self-signed cert any more.
Alfa 1000mW 1W 802.11b/g USB Wireless WiFi Network Adapter With Original Alfa Screw-On Swivel 9dBi Rubber Antenna works great for me for $35. Using kismet or your choice of promiscuous sniffing tool.
If the interference is 2.4-based 802.11b/g, you'll be able to find it. Won't help you any with 802.11n, which may just be your problem. Might be someone's 2.4GHz phone. Might be someone who microwaves a bunch of stuff. 2.4GHz is a swap free-for-all.
Most cheap UPS deliveries are handled by the USPS these days. They call it "UPS Mail Innovations". Some people don't like it when charged the full rate for UPS who just dumps it to the USPS for half.
First, see if your current domain Registrar is one of 13 .ORG Registrars that are supporting DNSSEC right now:
http://www.pir.org/get/registrars?order=field_dnssec_value&sort=desc.
If your .ORG domain Registrar is not listed as providing DNSSEC support, transfer your domain to GoDaddy or one of the other 12 .ORG Registrars with DNSSEC support.
Then generate your keys, sign your zone, and provide your Registrar your DS key. Anyone using a DNS server with DNSSEC enabled and ITAR keys will have the .ORG key and follow the chain to your domain. Anyone using a number of DLVs will also find the .ORG key.
Full support will work once the Root zone is signed, and then the ITAR will no longer be needed, and the DLVs will not be needed at all as more TLDs become signed.
If you're totally green to DNSSEC and didn't get the alphabet soup, you'll need to do some reading.
There is a Firefox add-on, DNSSEC Validator, which appears to work for the pir.org zone, as well as my own roysdon.net zone. Both are DNSSEC signed, although my roysdon.net is found in the DLV.
You can point the tool to use Comcast's DNSSEC trial resolver which is DLV-enabled at 68.87.68.170. .SE.
You can trial Comcast's DNSSEC trial resolved which does not have DLV support at 68.87.64.154 and rely only on the Root signature and previously published ccTLDs like
pir.org is an example of a zone which you can verify just by having the root zone's key. The root signs .ORG, and .ORG has signed pir.org. .NET is signed. Well, also until Registrars add a way so that .ORG owners can sign their zones.
As opposed to DLV-enabled zones, like mine, which rely on dlv.isc.org until
FYI, OpenDNS does not and will not support DNSSEC. DNSSEC breaks their model of typo-squatting, and filtering in general.
No, nor while it have ipv6 records. Why would they really care about tech? The real motive is profit. No profit in slowing down dns queries with DNSSEC or potential problems right now with broken ipv6 transit or clients.
Speaking of SSH and the like, the solution to this sort of madness is simple.
Arrange to have someone purchase a drive ahead of time for you in the destination country. Dd your drive to a drive that you leave in a secure location at home. Rsync your data over ssh to the remote PC with your drive before you leave. Securely wipe your HDD and use your computer manufacturer's restore DVD to reinstall. Cross boarder, if laptop is seized, buy new laptop at destination. Pop drive with data in laptop (new or otherwise) and continue on.
One return, do the same thing with changed data (rsync diff over ssh to your home PC) and repeat secure wiping of HDD and restore DVD.
A little hassle, but no way except you being framed could anything ever be found, and all your data is safe. Worst case you are out a laptop or two while they are searched.
This is a scam just like the many stratosphere airship scam companies that have been around in the last decade or so. They have no working product. They have no customers. It's all just a scam.
previous scam links
I don't get why you wouldn't have dual-redundant power supplies on all devices (routers, switches, servers), one on transfer switch A and the other on transfer switch B, each connecting to different backup power sources. Further, these should be tested on a regular basis (at least monthly). Test transfer switch A on the 1st, and transfer switch B on the 15th.
Seems like a design flaw here and/or someone was just being cheap.
Meh, when done right, it just looks like a long ssl and/or vpn tunnel session.
You really cannot do much to filter/firewall this sort of bypass for the technical user. Unless you allow whitelist-only access to https/ssl sites and/or force corporate-only machine access with corporate-installed SSL CAs that decrypt SSL traffic and re-encrypted (putting the corporate proxy as a man-in-the-middle) you have no way to stop this.
The real trick is blocking all "leaking" dns and apps. Socks leaks badly, as does flash, java and many other plugins. Just firewalling all outbound traffic except your tunnel works, but will require a dedicated machine.
http to a remote proxy over openvpn (ssl) is a bit more efficient than socks over ssh and clearly better than socks over ssh over ssl.
As I maintain my own DNS servers and such, I was curious how this worked. Here's what I learned with 15 minutes of research:
My first stop was to see the root.zone and I looked for these new TLDs, curious to see how they would show up in a Latin-based zone file. Ah, I spotted these odd XN-- zones and then knew what to dig into more.
Take for instance (I pasted a Unicode domain, but Slashcode won't show it) which is handled by ns[1-3].dotmasr.eg.:
$ dig ns (Unicode domain)
; > DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 > ns (Unicode domain) ;; QUESTION SECTION: ;.(Unicode domain) IN NS ;; ANSWER SECTION:
. 3600(Unicode domain) IN NS ns1.dotmasr.eg.
. 3600 (Unicode domain)IN NS ns2.dotmasr.eg.
. 3600(Unicode domain) IN NS ns3.dotmasr.eg.
If you look in the root.zone file, you will see that the ASCII/Latin version of this zone is really XN--WGBH1C.:
XN--WGBH1C. NS NS1.DOTMASR.EG.
XN--WGBH1C. NS NS2.DOTMASR.EG.
XN--WGBH1C. NS NS3.DOTMASR.EG.
TLD Reserved Domains has a list of the current mappings. ToASCII and ToUnicode are the methods to convert back and forth which links to RFC 3490 which has the nitty gritty details.
(meh, Slashcode doesn't support Unicode encoding, but I can see the Unicode domain name I am pasting in before I hit Preview in Firefox)
Also, the whole switching from right to left in Latin characters to left to right in some Unicode is odd when trying to edit!
Too true. I wonder what the ratio is of addicted flash-game players like this is to un/under-employed folks?
I hate to see Novell die (I was a CNA way back in the day, and learned NetWare 3.x in high school), but I think it'd be for the best interest of FOSS due to their taintedness with Microsoft.
Here's what I think should occur:
RedHat should set up a third-party company that they own. That company should buy Novell. That company should sell all non-tainted assets to RedHat.
Then what is left are the tainted bits the third-party is holding. Let it just die or shut down or whatever it is that you can do with a corporation to put it out of its misery.
I second this advice. I don't care about other services, so denyhosts is good enough for me. I like the shared database nature, much like spam databases.
Implement one-time passwords for new users. One time in, push public key, password no longer works. Use pub/priv keys only. Then every failed password auth can be set to fail after 1 attempt, and you can spread the goodness with denyhosts.
Just saw an add for $29.99/month Comcast internet + cable (probably just broadcast, dunno) for 1 year. I think I cancelled my service too soon though (just last month). How long do I have to be "not a customer" to be a "new customer" ? Hmm, and IPv6 native service isn't that far away either. I'll probably switch back.
Uhm, no. Just like STOked is its own show, CAS and LAS have been their own shows.
Jupiter Broadcasting.
SSL CA authority needs to be tied to domain hierarchy.
This sort of domain-based-CA's should be able to be installed via DNS and DNSSEC should be continue to be rolled out, all the way to the client (browsers should have methods to verify root DNSSEC, and follow the chain).
With SSL based on domain hierarchy, you need to know only the root DNS server's DNSSEC key. Everything else flows down from that.
Then CNNIC would only control .CN. The US Gov would theoretically only control .US, .GOV, .EDU. .COM, .NET, .ORG should be run by (as much as I hate to say it) the UN.
I already put SSH key fingerprints in my DNS and verify with DNSSEC-enabled openssh/bind-resolvers. SSL and/or SSL fingerprints could easily be done, if not just the entire CA public key.
Yes, at which time they could tell closed-source clients to install open-source plugins or open-source and/or more-friendly (Theora-supporting) browsers.
Or someone comes up with a license-free, plugin free solution for those closed-source clients like HTML5 Theora video codec for Silverlight. Wait, someone has done that, and they'll be releasing it as OSS soon. That solves newer IE clients, older IE clients can be told to upgrade anyway, and Safari users can be told to switch browsers because Apple is clueless (or someone will write a solution such as the Silverlight player for Theora but to work with Gecko/Safari).
Disks fail.
Buy a cheap raid system and have an offline disk backup system.
I doubt it very much. If the video is good enough for my purposes today, it will be good enough tomorrow.
Suit yourself, you just want to argue. I'm done.
Factory-pressed CDs have superior longevity to any storage technology currently available to the consumer.
Loading 1000s of CDs ripped to FLAC and re-encoded to MP3s takes me only the transfer time limited to my phone (limited to USB2 or whatever the phone supports). How long does it take to do it if you have them only stored in CD format and have to re-rip them? I can have multiple quality levels of MP3s as well for devices that doesn't sort as much (like my kids' cheaper cell phones which support smaller microSD cards). I can run batch jobs to re-encode these without any human intervention. Your method costs hundreds of human hours of intervention flipping CDs (again) for which I've already done.
Again, you just want to argue, you've no clue what you're talking about. Stating two facts about disks failing and CDs lasting longer doesn't discount what I've said as accurate. I'll only ever lose more than 1-2 days of new data at most, because I've RAID systems in place and 3 offline backup systems that I rotate through (plus two off-site on-line backups). I'll never have to re-encode my CDs because I have 100% perfect double-verified FLAC versions.
Stating an uninformed opinion about encoding quality of today being find for tomorrow doesn't discount what I said about keeping originals. "640k of memory is enough for anyone." Yup. Bandwidth/disk gets cheaper and cheaper, for instance, my first MP3 player held 32mb, so I could just hold a CD if I encoded very lossy, but then I had to re-rip when I got a few hundred mb MP3 player... twice was enough, never again, flac saves the day and I've never ripped a CD a second time. Now I use 256kb/s vbr encoding, but I've changed at least 3 different times for my MP3s since I went to FLAC, and twice for my Oggs. Even Youtube encodes at least 2-3 times (SD, and different HD levels).
Reply all you want, but I'm done.
Disk is cheap. Not storing your original recording doesn't make sense, even with sticking with just Ogg Theora / OSS methods.
Ogg Theora will continue to evolve and improve. Without a doubt you will want to re-encode to take advantage of these improvements.
I crossed that logic bridge a long time ago with my CD collection. I just rip once to FLAC, and re-encode for whatever I need (usually just Ogg Vorbis, but sometimes, like on cell phones, you don't have support, so you want to re-encode with the best fidelity possible, and re-encoding from another compressed format is always more lossy than from flac/source).
From my point of view, if I'm a content provider and I don't want to lose eyeballs, I'm going to encode and support both.
Give the end user the support for all 4 of the different options (OGV native, H.264 native, H.264 via flash, or direct download for playback with non-plugin) and lose no eyeballs. To me, that's the right way to go.
The "concession" is on the side of the end-user to have a crappier experience.
The informed end-user can have native H.264 support, or the enlightened FOSS end user can have Ogg Theora support.
To me, Video for Everyone is about choice. The end user gets to choose.
Video for Everyone supports all 4 classes of users (the 4th class is the direct-link class who will download it and play it outside of a plug-in).
It's just a bit of code, and requires only two encodings.