Wrong. Redundancy wouldn't multiply the cost by 2x.
Why ? I counted 4 Thumpers: 2 act as the active
servers, 2 act as the data backup servers. Only the active servers
may need system-wise redundancy. The backup servers are fine with
disk-wise redundancy (raid mirroring, which I already accounted for).
So even redundancy would only bring the number of Thumpers to 6 (4 for
the 1st and 2nd set of storage servers, 2 for backup). This is 48 (TB) *
6 (Thumpers) * 1200 ($/TB) = $346k. Still far from half a mil,
and this includes the overestimations of my original post (buy the
drives from Dell or OEM and worst case you end up spending $500-600/TB).
Yes it is reasonable to run 4 Thumpers with 1-TB drives. Read the
OpenSolaris ZFS mailing list, some people are doing just that.
You are wrong when you say "the number of concurrent users queued up
against reads & writes on a given spindle goes way up".
Previous situation: 1666 mailbox/drive (60 MB quota, assuming 100-GB drives).
With 4 Thumpers: 1000 mailbox/drive (1 GB quota, 1-TB drives).
That's actually lower !
Buying/configuring/administering 4 Thumpers for 5 years probably cost
$10-20k in people, tops. Maybe as low as $5k if your company is
efficient and not full of red-tape crap, such as a startup. A friend
of mine (working for one, precisely) just bought a Thumper. He spent
a few hours on the phone with Sun negotiating a good price, bought one
with the smallest drives, 250 GB, and replaced them with 1-TB ones he
bought himself at $130 piece (he wouldn't accept Sun's price of
$1000+/TB), this saved him more than $20k. Anyway he expects to spend
a week or 2 fine-tuning it, then once in prod maybe he will get
a drive failure every other month or so. This is an example where
a Thumper is clearly not going to cost much more than $5k in people.
"Then you have to deal with tape backup systems (which usually cost 2-3x
the storage cost per unit)" Tape is dead. Tape is being replaced
with disk. Part of the reason is precisely because, as you said (!) it costs
2-3x more than disk. (At least we agree on something). Read my original post,
I already accounted for a disk-based backup system in my numbers.
As a footnote, some startups do deal with 100k users or more. Hotmail
(on-topic, isn't it) had 100k subscribers 3 months after the site
launched (source: Founder at Works, quote from Sabeer Bhatia, cofounder
of Hotmail).
It does NOT cost hundreds of thousands of dollars in people to manage 4 freaking Thumpers in 16 RU, 28 inches of rack space. If you think it does, you would never succeed in founding a startup that has to be as efficient as possible.
50,000 mailboxes, 1 GB each, let's overestimate and multiply this by 4
(2x for raid mirroring, 2x for a disk-based backup on a raid mirror), so
you need about 200 TB of raw storage. 192 TB can be provided by 4 Thumpers
(Sun Fire x4500, 4 rack units) with 48 1-TB disks each (pretty soon Sun
will offer 1.5-TB disks), and the 4 of them fit in only 16 rack units.
Assuming you are getting ripped off by Sun, let's overestimate again and
say you pay $1200/TB (raw disks are 10 TIMES cheaper: $120/TB). That's
192*1200 = $230k.
A Thumper is rated 1800W max, let's overestimate and say it actually does
consume 1800W continuously and let's say you also waste 1800W on the A/C
to cool 1 Thumper. So running and cooling the 4 Thumpers consumes
1800*2*4 = 14.4kW. At $.01kWh, running them 24/7 for 5 years would cost
you 14.4*24*365.25*5*.01 = $6300.
Despite all this overestimations, the grand total is $230k + $6300 = $236k.
Half a mil you said ? I just saved you $500k-$236k = $264k:)
The original author's method, my method, and self-signed certs are all vulnerable to MITM attacks. The advantage over self-signed certs is: no annoying pop-up, and no need to explicitely use the HTTPS URL (which are the original goals of obfuscated TCP).
Yeah I was looking at the stream cipher, Salsa20 (never heard about it before), and I see that djbdns distributes very fast implementations (less than 1 cycle/byte on amd64 holly sh1t!). Traditional TLS/SSL ciphers like AES are indeed 2 orders of magnitude (base 2) slower.
Run your websites on different ports, you have 65535 of them per IP. Make http://site1/ redirect to https://site1:1111/, http://site2/ redirect to https://site2:2222/, etc. I concede this prevents users from directly typing the https url in their address bar as they don't know the port number in advance, but again 99% of the users let themselves be redirected to the https content on most websites anyway (except paranoids like me:P).
Use certs with the "subjectAltName" X.509 extension that let you create a single cert valid for multiple DNS names. I do this (with a CA I created & control), it works very well. The downside is that I think commercial CAs make you pay extra bucks to sign such certs (if they even accept to do that).
Anybody remembers what hapenned to RFC 2817 ? It tried to address this very pb by introducing the "Upgrade: TLS/1.0" header and the "426 Upgrade Required" status code, but I don't think any browser or server implement them.
I read the technical details and they talk about an advert being encoded in the CNAME, to distribute a curve25519 key and a port number. But they could have done much simpler using technology that already exists: encode the 160-bit SHA1 fingerprint of an X.509 certificate and a port number in the CNAME (only 32 chars needed in base32). Then connect to this port using HTTPS and simply verify that the certificate matches the fingerprint ! Advantages:
This technique works using standard TLS/SSL technology, no need to reinvent a poor man's TLS protocol like they did with Salsa20/8, Curve25519, Poly1305, etc.
It is just as secure as their "Obfuscated TCP" (both techniques rely on the DNS records not having been tampered).
The SHA1 fingerprint being encoded in the CNAME allows the browser to verify its validity without prompting the enduser with scary dialog boxes (and it also works with self-signed certs).
And as a bonus, the fact a standard HTTPS server is running allows endusers who really want true security to explicitely connect to the HTTPS URL by themselves (without relying on the CNAME trick). Doing this would make the browser verify the validity of the cert using the normal way (scary dialog boxes... or not if the cert's CA is trusted).
[A pseudorandom token] doesn't really stop it. All it does is reduce the problem to a cryptographic attack -- which is subject to brute force.
Saying that is like saying "cryptography doesn't really provide privacy, because it is subject to brute force". Of course pseudorandom tokens stop CSRF attack (when implemented properly).
I personally have the exact same stuff on my thumb drive - my resume and some cracking tools.
Hello, this is John, your boss's boss from Asus. We found your thumb drive plugged in one of our server used to build Vista images. Are you available monday 9:00am for a quick meeting ? We need to have a little talk.
Bizarely the video works from one of my other machines running Firefox 2.0.0.14, but not from my machine running Firefox 1.5.0.13. I tracked down the pb to a 403 Forbidden reply received from a *.googlevideo.com server for the URL http://v21.cache.googlevideo.com/get_video?video_id=pHO1JTNPPOU&origin=mia-v232.mia.youtube.com&signature=... Now go figure why one gets a 403 while the other streams the video just fine. I don't have time to debug youtube's website and their architecture make it difficult anyway (see the signature=xxx parmeter in the query string).
I am really pissed of: Youtube has removed the video. Anyone has a mirror ? How come it always happen to me. 80% of the Youtube videos people send are taken down before i have time to watch them.
Why do so many people seem to hate theses beta tags ? You are in effect complaining about their products being too stable and polished to be called beta ! Vendors already have different views on what "beta" means, eg. a Vista RC1 might be less stable than a Firefox "beta" version even though conceptually the beta stage preceeds the RC stage.
It looks like nobody but you realized it. The fact is that it is much easier to maintain a reliable copy of digital data when it is live (ie. copied around from time to time), than to maintain it on the same media for 25 years.
If it were me I would do it this way: rent/buy 3 servers (colo or hosted) on 3 different continents to maintain 3 copies of this data. Checksum it. On each server, verify the checksum periodically. When a corruption is detected, fetch a good copy from one of the 2 other servers. (This is technically what Google is doing in its datacenters with GFS.) Sure this solution requires (a little bite of) maintainance overtime. Once in a while a datacenter will relocate and you may have to rebuild a server, a hosting company might go bankrupt, etc. But IMO it is by far the most reliable way to store data with virtually zero chance of losing it.
As explained in the BBC article, flying over one of the poles is not necessary to fly forever. This team is now working on a defense project codenamed Vulture to extend their design to be able to fly non-stop for 5 years on any spot on the Earth's surface. Although they don't mention why Zephyr couldn't fly more than 84 hours, presumably it was either because it wasn't able to recharge its batteries fast enough during daytime, or they voluntarily stopped the experiment after 84 hours. In any case it looks like their design is not far from being able to "fly forever".
Slashdot Mirror
The more common variation of 3DES uses 3 keys and provides effectively 112 bits of security. This is 2^56 more secure than DES, not 2^52.
Wrong. Redundancy wouldn't multiply the cost by 2x.
Why ? I counted 4 Thumpers: 2 act as the active servers, 2 act as the data backup servers. Only the active servers may need system-wise redundancy. The backup servers are fine with disk-wise redundancy (raid mirroring, which I already accounted for).
So even redundancy would only bring the number of Thumpers to 6 (4 for the 1st and 2nd set of storage servers, 2 for backup). This is 48 (TB) * 6 (Thumpers) * 1200 ($/TB) = $346k. Still far from half a mil, and this includes the overestimations of my original post (buy the drives from Dell or OEM and worst case you end up spending $500-600/TB).
Yes it is reasonable to run 4 Thumpers with 1-TB drives. Read the OpenSolaris ZFS mailing list, some people are doing just that.
You are wrong when you say "the number of concurrent users queued up against reads & writes on a given spindle goes way up". Previous situation: 1666 mailbox/drive (60 MB quota, assuming 100-GB drives). With 4 Thumpers: 1000 mailbox/drive (1 GB quota, 1-TB drives). That's actually lower !
Buying/configuring/administering 4 Thumpers for 5 years probably cost $10-20k in people, tops. Maybe as low as $5k if your company is efficient and not full of red-tape crap, such as a startup. A friend of mine (working for one, precisely) just bought a Thumper. He spent a few hours on the phone with Sun negotiating a good price, bought one with the smallest drives, 250 GB, and replaced them with 1-TB ones he bought himself at $130 piece (he wouldn't accept Sun's price of $1000+/TB), this saved him more than $20k. Anyway he expects to spend a week or 2 fine-tuning it, then once in prod maybe he will get a drive failure every other month or so. This is an example where a Thumper is clearly not going to cost much more than $5k in people.
"Then you have to deal with tape backup systems (which usually cost 2-3x the storage cost per unit)" Tape is dead. Tape is being replaced with disk. Part of the reason is precisely because, as you said (!) it costs 2-3x more than disk. (At least we agree on something). Read my original post, I already accounted for a disk-based backup system in my numbers.
As a footnote, some startups do deal with 100k users or more. Hotmail (on-topic, isn't it) had 100k subscribers 3 months after the site launched (source: Founder at Works, quote from Sabeer Bhatia, cofounder of Hotmail).
It does NOT cost hundreds of thousands of dollars in people to manage 4 freaking Thumpers in 16 RU, 28 inches of rack space. If you think it does, you would never succeed in founding a startup that has to be as efficient as possible.
Read my post. I already accounted for a backup.
Half a mil ? Really ? Let's see.
50,000 mailboxes, 1 GB each, let's overestimate and multiply this by 4 (2x for raid mirroring, 2x for a disk-based backup on a raid mirror), so you need about 200 TB of raw storage. 192 TB can be provided by 4 Thumpers (Sun Fire x4500, 4 rack units) with 48 1-TB disks each (pretty soon Sun will offer 1.5-TB disks), and the 4 of them fit in only 16 rack units.
Assuming you are getting ripped off by Sun, let's overestimate again and say you pay $1200/TB (raw disks are 10 TIMES cheaper: $120/TB). That's 192*1200 = $230k.
A Thumper is rated 1800W max, let's overestimate and say it actually does consume 1800W continuously and let's say you also waste 1800W on the A/C to cool 1 Thumper. So running and cooling the 4 Thumpers consumes 1800*2*4 = 14.4kW. At $.01kWh, running them 24/7 for 5 years would cost you 14.4*24*365.25*5*.01 = $6300.
Despite all this overestimations, the grand total is $230k + $6300 = $236k.
Half a mil you said ? I just saved you $500k-$236k = $264k :)
Sooo do they mean .03 cents or .03 dollars ?
The original author's method, my method, and self-signed certs are all vulnerable to MITM attacks. The advantage over self-signed certs is: no annoying pop-up, and no need to explicitely use the HTTPS URL (which are the original goals of obfuscated TCP).
No, because it would be possible to use the subjectAltName X.509 extension.
Thanks for the links. It looks like the best solution for virtual HTTPS hosting in the long term is maybe this TLS extension mentioned by someone else: http://en.wikipedia.org/wiki/Server_Name_Indication
s/djbdns/djb/
Yeah I was looking at the stream cipher, Salsa20 (never heard about it before), and I see that djbdns distributes very fast implementations (less than 1 cycle/byte on amd64 holly sh1t!). Traditional TLS/SSL ciphers like AES are indeed 2 orders of magnitude (base 2) slower.
Anybody remembers what hapenned to RFC 2817 ? It tried to address this very pb by introducing the "Upgrade: TLS/1.0" header and the "426 Upgrade Required" status code, but I don't think any browser or server implement them.
I read the technical details and they talk about an advert being encoded in the CNAME, to distribute a curve25519 key and a port number. But they could have done much simpler using technology that already exists: encode the 160-bit SHA1 fingerprint of an X.509 certificate and a port number in the CNAME (only 32 chars needed in base32). Then connect to this port using HTTPS and simply verify that the certificate matches the fingerprint ! Advantages:
Saying that is like saying "cryptography doesn't really provide privacy, because it is subject to brute force". Of course pseudorandom tokens stop CSRF attack (when implemented properly).
Hello, this is John, your boss's boss from Asus. We found your thumb drive plugged in one of our server used to build Vista images. Are you available monday 9:00am for a quick meeting ? We need to have a little talk.
PS: bring 1 or 2 empty boxes.
-John
Bizarely the video works from one of my other machines running Firefox 2.0.0.14, but not from my machine running Firefox 1.5.0.13. I tracked down the pb to a 403 Forbidden reply received from a *.googlevideo.com server for the URL http://v21.cache.googlevideo.com/get_video?video_id=pHO1JTNPPOU&origin=mia-v232.mia.youtube.com&signature=... Now go figure why one gets a 403 while the other streams the video just fine. I don't have time to debug youtube's website and their architecture make it difficult anyway (see the signature=xxx parmeter in the query string).
I am really pissed of: Youtube has removed the video. Anyone has a mirror ? How come it always happen to me. 80% of the Youtube videos people send are taken down before i have time to watch them.
"Oops."
Why do so many people seem to hate theses beta tags ? You are in effect complaining about their products being too stable and polished to be called beta ! Vendors already have different views on what "beta" means, eg. a Vista RC1 might be less stable than a Firefox "beta" version even though conceptually the beta stage preceeds the RC stage.
and placing the address bar under the tabs. Dude don't forget this capital feature !
It looks like nobody but you realized it. The fact is that it is much easier to maintain a reliable copy of digital data when it is live (ie. copied around from time to time), than to maintain it on the same media for 25 years.
If it were me I would do it this way: rent/buy 3 servers (colo or hosted) on 3 different continents to maintain 3 copies of this data. Checksum it. On each server, verify the checksum periodically. When a corruption is detected, fetch a good copy from one of the 2 other servers. (This is technically what Google is doing in its datacenters with GFS.) Sure this solution requires (a little bite of) maintainance overtime. Once in a while a datacenter will relocate and you may have to rebuild a server, a hosting company might go bankrupt, etc. But IMO it is by far the most reliable way to store data with virtually zero chance of losing it.
As explained in the BBC article, flying over one of the poles is not necessary to fly forever. This team is now working on a defense project codenamed Vulture to extend their design to be able to fly non-stop for 5 years on any spot on the Earth's surface. Although they don't mention why Zephyr couldn't fly more than 84 hours, presumably it was either because it wasn't able to recharge its batteries fast enough during daytime, or they voluntarily stopped the experiment after 84 hours. In any case it looks like their design is not far from being able to "fly forever".
That's what SHE said ?