Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Hacker's Replacement for Gmail

dbpmail.net

Post reply on HN
Print view View original

61–70 of 218 posts

Re: A Hacker's Replacement for Gmail

#61

Post by [deleted] »

mbell wrote: post #34
bigiain wrote: post #23

Earlier quoted context omitted.

The difference today is that not only should I assume that Google sysadmins could read my mail, but there's now pretty convincing arguments that Google are sending all my (as a non-US person) email to the NSA - who're storing it forever "just in case it turns out useful". I'm somewhat less concerned about rogue individual sysadmins curiously snooping on my mail, than I am about the NSA's comprehensive perpetual archi…

What? Have you been following this topic at all? Exactly where are these convincing arguments that google is sending all e-mail to the NSA? Links? Data? Do you have anything that supports this at all? There is the telephone stuff that was leaked, which has been well known since 2006 [0]. But, where is this miraculous evidence that google is handing everything over to the NSA? [0] http://yahoo.usatoday.com/news/washin…

[deleted]

Re: A Hacker's Replacement for Gmail

#62

Post by bigiain »

joe_bleau wrote: post #59
magic_haze wrote: post #55

To play the devil's advocate, what exactly is the practical use of all this if most of your family and friends are on Gmail (and couldn't be arsed to figure out pgp)? From what I can see, your emails will now be sent in the clear over the internet, instead of staying within google's servers. Either way, the government's going to get your data, but at least you're protected against... /more/ unscrupulous people snoopi…

I see encrypted connections to/from gmail all the time. Here's an example from a test I just ran: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.79.27]:25: TLSv1 with cipher RC4-SHA Anonymous TLS connection established from mail-yh0-f48.google.com[209.85.213.48]: TLSv1 with cipher RC4-SHA

Hmmm, no Perfect Forward Secrecy on RC4-SHA...

Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?

Re: A Hacker's Replacement for Gmail

#63

Post by joe_bleau »

bigiain wrote: post #62
joe_bleau wrote: post #59

Earlier quoted context omitted.

I see encrypted connections to/from gmail all the time. Here's an example from a test I just ran: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.79.27]:25: TLSv1 with cipher RC4-SHA Anonymous TLS connection established from mail-yh0-f48.google.com[209.85.213.48]: TLSv1 with cipher RC4-SHA

Hmmm, no Perfect Forward Secrecy on RC4-SHA... Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?

It could be an artifact of my postfix configuration. Looking over a few logfiles, here are the ciphers I've seen recently (all servers, not just gmail):

ADH-AES256-SHA (256/256 bits) AES128-SHA (128/128 bits) AES256-SHA (256/256 bits) DHE-RSA-AES256-SHA (256/256 bits) EDH-RSA-DES-CBC3-SHA (168/168 bits) RC4-SHA (128/128 bits)

Re: A Hacker's Replacement for Gmail

#64

Post by vu3rdd »

daurnimator wrote: post #38

Does anyone have a gmail exporter? i.e. something that imports email from gmail WITH labels.

You can use offlineimap to do that. Every label is an imap folder. offlineimap allows what they call as "folder filters", using which one can write a short python function parameterised over the folder name.

Re: A Hacker's Replacement for Gmail

#65

Post by dualboot »

etherael wrote: post #50
jervisfm wrote: post #33

Earlier quoted context omitted.

The point about trusting hosting providers is an interesting one. Indeed, when renting a Virtual Private Server from a service provider, you have no choice but to trust them to keep your data safe. This made we wonder: would it be possible to actually secure the server in such a manner that the hosting party won't have access to your stuff without your say so ? I think you can (sort of) do this already with having so…

I have a dedicated server with encrypted partitions and admin backdoors turned off at ovh. So theoretically they shouldn't be able to access the running system, and if they take it down to access the partitions directly, they're encrypted so that won't work either.

The right answer. With a design that focuses on simplicity ( reducing the entry points ) you can be pretty well assured that if someone attempts to gain access to your data you will likely know.

For me that is an important factor. I rather dislike the fact that in scenarios like Gmail and other providers of their ilk -- access is provided transparently to a third party.

Running your own server can give you a reasonable expectation of privacy. Even in a hosted/colocated environment if you take the time and effort.

Re: A Hacker's Replacement for Gmail

#66

Post by Sami_Lehtinen »

etherael wrote: post #50
jervisfm wrote: post #33

Earlier quoted context omitted.

The point about trusting hosting providers is an interesting one. Indeed, when renting a Virtual Private Server from a service provider, you have no choice but to trust them to keep your data safe. This made we wonder: would it be possible to actually secure the server in such a manner that the hosting party won't have access to your stuff without your say so ? I think you can (sort of) do this already with having so…

I have a dedicated server with encrypted partitions and admin backdoors turned off at ovh. So theoretically they shouldn't be able to access the running system, and if they take it down to access the partitions directly, they're encrypted so that won't work either.

That's why they take memory snapshot first, which is trivial with VPS and then pick encryption keys from it to access encrypted volumes. This is well known method and works with pure hardware machines too with physical access. It's great question when you get to server, to shut it down or leave on. If on, it could destroy data, if turned off encryption keys are gone. I think it would require some individual case analysis before deciding which one is better approach.

Re: A Hacker's Replacement for Gmail

#68

Post by cheese1756 »

mbell wrote: post #34
bigiain wrote: post #23

Earlier quoted context omitted.

The difference today is that not only should I assume that Google sysadmins could read my mail, but there's now pretty convincing arguments that Google are sending all my (as a non-US person) email to the NSA - who're storing it forever "just in case it turns out useful". I'm somewhat less concerned about rogue individual sysadmins curiously snooping on my mail, than I am about the NSA's comprehensive perpetual archi…

What? Have you been following this topic at all? Exactly where are these convincing arguments that google is sending all e-mail to the NSA? Links? Data? Do you have anything that supports this at all? There is the telephone stuff that was leaked, which has been well known since 2006 [0]. But, where is this miraculous evidence that google is handing everything over to the NSA? [0] http://yahoo.usatoday.com/news/washin…

The issue is not what we know, but what we don't. Keep in mind, all we have is what was leaked. We only have a tiny glimpse into the massive amounts of post-9/11 surveillance. We can ascertain that the government is doing extensive amounts of surveillance on large amounts of people, and that the NSA has either refused to tell Congress the scope of the programs or outright lied about it (take a look at this (http://www.wired.com/dangerroom/2012/06/nsa-spied/) article from a year ago , and look at Clapper's "Not Wittingly" statement).

To ask for "Links? Data? Do you have anything that supports this at all?" is asking the wrong question, since the amount that is public is incredibly small (just a tiny fraction would be my guess, but all we can do is make estimates). The question is, Is it reasonable to assume that there is more surveillance? The answer is yes, and to assume that there is detailed email surveillance, either at the ISP level, through backdoors, or through direct cooperation is not unreasonable.

Re: A Hacker's Replacement for Gmail

#69

Post by bigiain »

etherael wrote: post #50
jervisfm wrote: post #33

Earlier quoted context omitted.

The point about trusting hosting providers is an interesting one. Indeed, when renting a Virtual Private Server from a service provider, you have no choice but to trust them to keep your data safe. This made we wonder: would it be possible to actually secure the server in such a manner that the hosting party won't have access to your stuff without your say so ? I think you can (sort of) do this already with having so…

I have a dedicated server with encrypted partitions and admin backdoors turned off at ovh. So theoretically they shouldn't be able to access the running system, and if they take it down to access the partitions directly, they're encrypted so that won't work either.

Possibly some too-cynical questions…

Do you think ovh is any less beholden to GCHQ than Google et al are to the NSA?

Do you think your encrypted partitions and turned-off admin backdoors protect you much against people with physical access to the hardware?

Re: A Hacker's Replacement for Gmail

#70

Post by bigiain »

joe_bleau wrote: post #63
bigiain wrote: post #62

Earlier quoted context omitted.

Hmmm, no Perfect Forward Secrecy on RC4-SHA... Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?

It could be an artifact of my postfix configuration. Looking over a few logfiles, here are the ciphers I've seen recently (all servers, not just gmail): ADH-AES256-SHA (256/256 bits) AES128-SHA (128/128 bits) AES256-SHA (256/256 bits) DHE-RSA-AES256-SHA (256/256 bits) EDH-RSA-DES-CBC3-SHA (168/168 bits) RC4-SHA (128/128 bits)

Curiously, I'm seeing a bunch of TLSv1:DHE-RSA-AES256-SHA:256 between one of my machines and google...

I wonder why/when the connections end up RC4-SHA instead?

Post reply on HN