[Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Saïvann Carignan]

I would like to know what are your thoughts on moving bitcoin.org on a
dedicated server with a SSL certificate?

I am considering the idea more seriously, but I'd like some feedback
before taking steps.

Saïvann

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Odinn Cyberguerrilla]

Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts

1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert certificate,
"DigiCert “may revoke a Certificate, without notice, for the reasons
stated in the CPS, including if DigiCert reasonably believes that” (…)
“Applicant is added to a government list of prohibited persons or entities
or is operating from a prohibited destination under the laws of the United
States” (…) “the Private Key associated with a Certificate was disclosed
or Compromised”"
In the same post I mentioned
"Bitcoin.org has no certificate, no encryption — a situation which has its
own obvious problems. Bitcoin.org currently sends users to download the
bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
certificate based on GeoTrust:
https://www.geotrust.com/resources/repository/legal/"

(Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
encrypted' examining it in a cursory fashion w/ Chrome)

Not sure how this would work, but it would be nice to see the content at
bitcoin.org encrypted, of course, but also further decentralized? how many
mirrors are there of bitcoin.org - not sure, but a few things that come to
mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin). 
There are many ways to decentralize something but that is just something
that comes to mind.

This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
of certain content

Some things to think about.

> I would like to know what are your thoughts on moving bitcoin.org on a
> dedicated server with a SSL certificate?
>
> I am considering the idea more seriously, but I'd like some feedback
> before taking steps.
>
> Saïvann
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Saïvann Carignan]

Forward secrecy:
I was definitively already interested in using this.

Binaries:
Sourceforge is not encrypted, actually. Although binaries hosting /
sharing could be a separate subject discussed later I think.

Revocation:
I guess we could just buy another SSL cert from another CA (I mean, if
that really happens). There's a few ones that are not US based.

Decentralization:
So long as we actually use DNS, the website is centralized :( However,
its content isn't (can be forked on GitHub), but regarding the domain
name, there is not much we can do against this AFAIK.

Saïvann



Le 2013-12-07 22:38, Odinn Cyberguerrilla a écrit :
> Hello, re. the dedicated server for bitcoin.org idea, I have a few thoughts
> 
> 1) I have commented in a blogpost of August 2013 at
> https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
> issues with CA related to bitcoin.org - where I mentioned something
> relative to the DigiCert certificate,
> "DigiCert “may revoke a Certificate, without notice, for the reasons
> stated in the CPS, including if DigiCert reasonably believes that” (…)
> “Applicant is added to a government list of prohibited persons or entities
> or is operating from a prohibited destination under the laws of the United
> States” (…) “the Private Key associated with a Certificate was disclosed
> or Compromised”"
> In the same post I mentioned
> "Bitcoin.org has no certificate, no encryption — a situation which has its
> own obvious problems. Bitcoin.org currently sends users to download the
> bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
> certificate based on GeoTrust:
> https://www.geotrust.com/resources/repository/legal/"
> 
> (Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
> encrypted' examining it in a cursory fashion w/ Chrome)
> 
> Not sure how this would work, but it would be nice to see the content at
> bitcoin.org encrypted, of course, but also further decentralized? how many
> mirrors are there of bitcoin.org - not sure, but a few things that come to
> mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin). 
> There are many ways to decentralize something but that is just something
> that comes to mind.
> 
> This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
> ('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
> https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
> of certain content
> 
> Some things to think about.
> 
>> I would like to know what are your thoughts on moving bitcoin.org on a
>> dedicated server with a SSL certificate?
>>
>> I am considering the idea more seriously, but I'd like some feedback
>> before taking steps.
>>
>> Saïvann
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Luke-Jr]

On Sunday, December 08, 2013 9:03:38 AM Saïvann Carignan wrote:
> Binaries:
> Sourceforge is not encrypted, actually. Although binaries hosting /
> sharing could be a separate subject discussed later I think.

Encryption is useless here. We want everyone to be able to download Bitcoin 
clients. Binaries on sourceforge are signed by multiple parties using gitian.

> Decentralization:
> So long as we actually use DNS, the website is centralized :( However,
> its content isn't (can be forked on GitHub), but regarding the domain
> name, there is not much we can do against this AFAIK.

So long as someone has root (or a user that can modify it), the website is 
centralised. To really solve this, we would need a dedicated server that 
accepts commands only when signed by N-of-M parties, inside a cage locked by 
padlocks with keys held by independent parties, with a SSL certificate issued 
by an authority that has multiple parties watch it every step of the way into 
that server.

Luke

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]

On 8 December 2013 12:37, Luke-Jr <luke@dashjr.org> wrote:

> Encryption is useless here. We want everyone to be able to download Bitcoin
> clients. Binaries on sourceforge are signed by multiple parties using
> gitian.
>
> > Decentralization:
> > So long as we actually use DNS, the website is centralized :( However,
> > its content isn't (can be forked on GitHub), but regarding the domain
> > name, there is not much we can do against this AFAIK.
>
> So long as someone has root (or a user that can modify it), the website is
> centralised. To really solve this, we would need a dedicated server that
> accepts commands only when signed by N-of-M parties, inside a cage locked
> by
> padlocks with keys held by independent parties, with a SSL certificate
> issued
> by an authority that has multiple parties watch it every step of the way
> into
> that server.


Malicious actors with root access to the server is another issue entirely.
Sure it's a problem, but it is not an argument not to have a properly
signed SSL certificate.

With out one, the exploit can be performed on routers to redirect traffic
through a third party alter the content of the site (like the links on
bitcoin.org to various wallet projects) and then onto the correct
destination. SSL at least mitigates that. For example it would be trivial
to impersonate Electrum's site or whatever, "change" the link on the fly
that appears on the trusted source bitcoin.org via BGP redirection. Now
users will be directed to the scammers site which could be identical except
for domain name and of course malicious binaries.

BGP redirection is a reality and can be exploited without much
expense/effort. MITM is a real world threat, not some theoretical
possibility - reports show it's happening on an unprecedented scale. SSL is
essential - that's a no-brainer. Sure other measures are important, but
without SSL there is almost no point to any of the other options.

SSL is so considered so important that the *HTTP 2.0 spec might be SSL
only*according to recent discussions at the W3C (
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html).

Drak

[-- Attachment #2: Type: text/html, Size: 2968 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula.org> wrote:
> BGP redirection is a reality and can be exploited without much

You're managing to argue against SSL. Because it actually provides
basically protection against an attacker who can actively intercept
traffic to the server. Against that threat model SSL is clearly— based
on your comments— providing a false sense of security.

We _do_ have protection that protect against that— the pgp signature,
but they are far from a solution since people do not check that.

(I'm not suggesting we shouldn't have it, I'm suggesting you stop
arguing SSL provides protection it doesn't before you manage to change
my mind!)

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

Issues that would need to be resolved:

1) Who pays for it? Most obvious answer: Foundation. However there's
currently a fairly clear line between the foundation website and the
bitcoin.org website. I personally am fine with the bitcoin foundation
funding the website, it's a lot closer to the bitcoin community than
github. But some people might care. So next step would be to contact the
Foundation board and see if they're willing to fund it.

2) Anti-DoS? I assume github handles this at the moment, though I doubt
there's anything to be gained from DoSing the informational website

3) Where does the server go? Ideally, a hosting provider that accepts
Bitcoin of course!

4) Who admins it?

5) Who controls DNS for it?

Right now I think Sirius still owns DNS for bitcoin.org which is nonsense.
He needs to pass it on to someone who is actually still involved with the
project. Again, the most obvious neutral candidate would be the Foundation.

So I think it's a good idea but there's a fair amount of work here. The
primary upside I see is that it opens the potential for adding
interactive/server-side code in future if we decide that would be useful.



On Sun, Dec 8, 2013 at 8:25 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula.org> wrote:
> > BGP redirection is a reality and can be exploited without much
>
> You're managing to argue against SSL. Because it actually provides
> basically protection against an attacker who can actively intercept
> traffic to the server. Against that threat model SSL is clearly— based
> on your comments— providing a false sense of security.
>
> We _do_ have protection that protect against that— the pgp signature,
> but they are far from a solution since people do not check that.
>
> (I'm not suggesting we shouldn't have it, I'm suggesting you stop
> arguing SSL provides protection it doesn't before you manage to change
> my mind!)
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3498 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn <mike@plan99.net> wrote:
> Right now I think Sirius still owns DNS for bitcoin.org which is nonsense.
> He needs to pass it on to someone who is actually still involved with the
> project. Again, the most obvious neutral candidate would be the Foundation.

I am opposed to Bitcoin Foundation having control of Bitcoin.org, and
I think it would be foolish of the foundation to accept it were it
offered.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On 8 December 2013 20:40, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn <mike@plan99.net> wrote:
> > Right now I think Sirius still owns DNS for bitcoin.org which is
> nonsense.
> > He needs to pass it on to someone who is actually still involved with the
> > project. Again, the most obvious neutral candidate would be the
> Foundation.
>
> I am opposed to Bitcoin Foundation having control of Bitcoin.org, and
> I think it would be foolish of the foundation to accept it were it
> offered.
>

What do you suggest though? We will need to trust someone (even in a group
each person can act autonomously).
The only thing I can suggest would be to hand the keys to the bitcoin
project lead.

Otherwise, who has admin rights to the code projects
(github/sourceforge/this mailing list)? Those people have proven they can
be trusted so far.

Drak

[-- Attachment #2: Type: text/html, Size: 1523 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Luke-Jr]

On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
> Otherwise, who has admin rights to the code projects
> (github/sourceforge/this mailing list)? Those people have proven they can
> be trusted so far.

Can someone explain how Sirius has proven the least bit untrustworthy?

Luke

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

On 8 December 2013 21:01, Luke-Jr <luke@dashjr.org> wrote:

> On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
> > Otherwise, who has admin rights to the code projects
> > (github/sourceforge/this mailing list)? Those people have proven they can
> > be trusted so far.
>
> Can someone explain how Sirius has proven the least bit untrustworthy?


It's not just about trust, there is the robustness factor: what if he
becomes sick, unavailable, hit by a bus? Others need the ability to pickup
and run with it. The control over the domain (including ability to renew
registration, alter nameservers) needs to be with more than one person.
That's why I suggest using the same people who have control over the
software project at sf,github.

[-- Attachment #2: Type: text/html, Size: 1151 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[theymos]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:

It's not just about trust, there is the robustness factor: what if he
becomes sick, unavailable, hit by a bus? Others need the ability to
pickup and run with it. The control over the domain (including ability
to renew registration, alter nameservers) needs to be with more than
one person. That's why I suggest using the same people who have control
over the software project at sf,github


The bitcoin.org domain is controlled by me, Sirius, and an anonymous
person. Control will not be lost if Sirius becomes unavailable.

SSL is probably a good idea, and it's probably also a good idea to
separate bitcoin.org from Github. I don't know that I trust Github. I'm
sure that you can find a sponsor for a dedicated server. Let us know if
DNS changes to bitcoin.org are required.

[-- Attachment #2: Type: text/html, Size: 1121 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Taylor Gerring]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

Maybe bitcointalk.org would like to donate a few BTC from the 6,000 BTC "new forum" fund to sponsor hosting?

On Dec 8, 2013, at 5:51 PM, theymos <theymos@mm.st> wrote:

>  I'm sure that you can find a sponsor for a dedicated server. 


[-- Attachment #2: Type: text/html, Size: 1104 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Jeremy Spilman]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

I can provide the server hardware and colocation (space, power, and  
bandwidth) if dedicated 50Mbit in 55 S. Market, San Jose, CA data center  
is acceptable.

If it needs more bandwidth than that, in a few months I hope to be getting  
space in LA with 1Gbit, but I can't commit to that now.


> On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
>> It's not just about trust, there is the robustness factor: what if he  
>> becomes sick, unavailable, hit by a bus? Others need the ability to  
>> >>pickup and run with it. The control over the domain (including  
>> ability to renew registration, alter nameservers) needs to be with more  
>> than >>one person. That's why I suggest using the same people who have  
>> control over the software project at sf,github
>The bitcoin.org domain is controlled by me, Sirius, and an anonymous  
> person. Control will not be lost if Sirius becomes unavailable.
>SSL is probably a good idea, and it's probably also a good idea to  
> separate bitcoin.org from Github. I don't know that I trust Github. I'm  
> sure that you can >find a sponsor for a dedicated server. Let us know if  
> DNS changes to bitcoin.org are required.

[-- Attachment #2.1: Type: text/html, Size: 1672 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Roy Badami]

> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.

I know this will be a controversial viewpoint in some quarters, but
I'm not a fan of anonymity, or of pseudonyms.  As far as I know
(please correct me if I'm wrong) all the core devs go by their real
names with the exception of Satoshi (and I would hope he no longer has
commit access? - only because I would hope that no-one has
pseudonymous commit access these days).  I don't see why this should
be different for the domain, the DNS and the rest of the
infrastructure...

Although that's separate from the question of who the registrant of
the domain should be (the registrant being the closest thing a domain
has to a recorded legal owner).  Who currently purports to be the
current legal owner of the domain?

IMHO the registrant should obviously be real and not WhoisGuard -
anonymous stuff like this always looks shady.  And surely the Bitcoin
Foundation is the obvious candidate to own the domain (just like
kernel.org is owned by the Linux Foundation).  But this may all be
moot unless the current legal owners are willing to assign the
domain...

roy

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Odinn Cyberguerrilla]

I've been lurking on this convo since it began, but I wanted to say
thanks, theymos

cheers to you all and yay for decentralization, wherever it leads.

-odinn
muh latest: http://github.com/ABISprotocol/ABIS

> On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
>
> It's not just about trust, there is the robustness factor: what if he
> becomes sick, unavailable, hit by a bus? Others need the ability to
> pickup and run with it. The control over the domain (including ability
> to renew registration, alter nameservers) needs to be with more than
> one person. That's why I suggest using the same people who have control
> over the software project at sf,github
>
>
> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
>
> SSL is probably a good idea, and it's probably also a good idea to
> separate bitcoin.org from Github. I don't know that I trust Github. I'm
> sure that you can find a sponsor for a dedicated server. Let us know if
> DNS changes to bitcoin.org are required.
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Sun, Dec 8, 2013 at 12:51 PM, Drak <drak@zikula.org> wrote:
> What do you suggest though? We will need to trust someone (even in a group
> each person can act autonomously).
> The only thing I can suggest would be to hand the keys to the bitcoin
> project lead.
>
> Otherwise, who has admin rights to the code projects
> (github/sourceforge/this mailing list)? Those people have proven they can be
> trusted so far.

My concern isn't a matter of trustworthyness, it's a matter of too
many eggs in one basket (especially a basket with potentially poor
jurisdictional locality).  The current control of the domain has
proven reasonably trustworthy, and if there is a concern for funding
our own server stuff that can be easily handled (e.g. if need be, I'd
pay for it myself, without being in control of it).

Also, in terms of effective lobbying/advocacy I worry that the
foundation would be unable to do an effective job if its saddled with
the belief that its in control of Bitcoin ("Why don't you just make
every transaction {...}": the answer is because its a decentralized
system and no one can unilaterally change it in ways its users would
hate, but it becomes complicated. It's crisper when its clear that
diverse and independant parties are in control of the popular
infrastructure).

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Saïvann Carignan]

> Issues that would need to be resolved:
> 
> 1) Who pays for it? Most obvious answer: Foundation. However there's
> currently a fairly clear line between the foundation website and the
> bitcoin.org <http://bitcoin.org> website. I personally am fine with the
> bitcoin foundation funding the website, it's a lot closer to the bitcoin
> community than github. But some people might care. So next step would be
> to contact the Foundation board and see if they're willing to fund it.

Actually I might find way to fund it. But I needed to have ACK &
comments from developers before anything.

> 2) Anti-DoS? I assume github handles this at the moment, though I doubt
> there's anything to be gained from DoSing the informational website

That is a fair question, we will need anti-DDoS. Unless something better
(and affordable) can be recommended, this would yet put another Bitcoin
website under CloudFlare.

> 4) Who admins it?

Obviously, I thought it would be important that the server is owned by
someone who can be trusted, with ssh access for all core developers.

> 5) Who controls DNS for it?

I'm not sure we'll get any change on this level. I have no idea if the
domain is in good hands, except for the fact that nothing bad happened
thus far. If anything, moving it to core developers (as intended when
the domain was registered) would make more sense IMO. But again, is it
possible, I don't know.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Roy Badami]

> > 5) Who controls DNS for it?
> 
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.

That's an interesting question.  The bitcoin.org domain is hiding
behind a WhoisGuard anonymous registration.  Why are we not allowed to
know who this domain belongs to?  Why are we being asked to trust some
unidentified party?

roy

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

> That's an interesting question.  The bitcoin.org domain is hiding
> behind a WhoisGuard anonymous registration.  Why are we not allowed to
> know who this domain belongs to?  Why are we being asked to trust some
> unidentified party?


It's done that way because it was originally registered by Satoshi. It's
now controlled by Sirius, who doesn't really take part in the project
anymore.

I bring this up because of the recent bitcointalk fiasco. AFAIK the domains
are registered and controlled in the same way. It's likely that the current
registrar isn't very secure.

[-- Attachment #2: Type: text/html, Size: 911 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Jeff Garzik]

On Sun, Dec 8, 2013 at 8:03 PM, Mike Hearn <mike@plan99.net> wrote:
> I bring this up because of the recent bitcointalk fiasco. AFAIK the domains
> are registered and controlled in the same way. It's likely that the current
> registrar isn't very secure.

I registered bitcointalk.org originally, then passed along control.
It is likely that the two domains are /not/ registered and controlled
in the same way.

The handling of bitcointalk.org was quite disappointing.  Even after
"control" passed from me to Sirius, he did not bother to change the
registrar credentials for months afterward, despite repeated urging.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

>
> > 4) Who admins it?
>
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
>

That is a really bad idea.  If there is not a CLEAR answer to "who admins
it", there will be a bunch of "I thought YOU were applying security
patches... no, I thought YOU were..." the first time it gets hacked.

So, the question is:  who wants to take responsibility for keeping
bitcoin.org safe and secure?

I am not going to do that, I've got too many other things to worry about.
It is exactly the type of thing the Foundation was setup to do, but if
y'all want to create some other organization to do it, then please make it
happen.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1275 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Saïvann Carignan]

>     > 4) Who admins it?
> 
>     Obviously, I thought it would be important that the server is owned by
>     someone who can be trusted, with ssh access for all core developers.
> 
> 
> That is a really bad idea.  If there is not a CLEAR answer to "who
> admins it", there will be a bunch of "I thought YOU were applying
> security patches... no, I thought YOU were..." the first time it gets
> hacked.
> 
> So, the question is:  who wants to take responsibility for keeping
> bitcoin.org <http://bitcoin.org> safe and secure?
> 
> I am not going to do that, I've got too many other things to worry
> about. It is exactly the type of thing the Foundation was setup to do,
> but if y'all want to create some other organization to do it, then
> please make it happen.
> 
> -- 
> --
> Gavin Andresen
> 

I fully agree that someone *must* be assigned to the task, otherwise
it's better keeping current hosting.

Perhaps that was implicit, but I can take this responsibility so long as
I can be replaced if required for any reason. On this regard, I agree
that the Foundation funding / owning / securing the server
infrastructure is a much better long term strategy.

This said, I also agree that it is a better idea to keep the domain and
website content independently owned and managed, for the reasons stated
by Gregory Maxwell.

If there isn't a good consensus on one of the two options I suggested, I
vote we don't lose more time on this question and keep focus with bigger
priorities.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Luke-Jr]

On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote:
> > 1) Who pays for it? Most obvious answer: Foundation. However there's
> > currently a fairly clear line between the foundation website and the
> > bitcoin.org <http://bitcoin.org> website. I personally am fine with the
> > bitcoin foundation funding the website, it's a lot closer to the bitcoin
> > community than github. But some people might care. So next step would be
> > to contact the Foundation board and see if they're willing to fund it.
> 
> Actually I might find way to fund it. But I needed to have ACK &
> comments from developers before anything.
> 
> ...
> > 4) Who admins it?
> 
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
> 
> > 5) Who controls DNS for it?
> 
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.

I don't think "core developers" should be directly in control here any more 
than the Foundation should. Developers are good for development, not 
necessarily web or server admin tasks. Only those directly involved in the 
needed roles should have access IMO.

Luke

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Patrick]

Have you considered black lotus dedicated servers?

On 12/08/2013 03:16 PM, Saïvann Carignan wrote:
>> Issues that would need to be resolved:
>>
>> 1) Who pays for it? Most obvious answer: Foundation. However there's
>> currently a fairly clear line between the foundation website and the
>> bitcoin.org <http://bitcoin.org> website. I personally am fine with the
>> bitcoin foundation funding the website, it's a lot closer to the bitcoin
>> community than github. But some people might care. So next step would be
>> to contact the Foundation board and see if they're willing to fund it.
> Actually I might find way to fund it. But I needed to have ACK &
> comments from developers before anything.
>
>> 2) Anti-DoS? I assume github handles this at the moment, though I doubt
>> there's anything to be gained from DoSing the informational website
> That is a fair question, we will need anti-DDoS. Unless something better
> (and affordable) can be recommended, this would yet put another Bitcoin
> website under CloudFlare.
>
>> 4) Who admins it?
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
>
>> 5) Who controls DNS for it?
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 3327 bytes --]

I too would be against the foundation taking control of hosting or the
domain. I have no reason at this time not to trust them, by checks and
balances are a good thing.
On Dec 8, 2013 12:29 PM, "Mike Hearn" <mike@plan99.net> wrote:

> Issues that would need to be resolved:
>
> 1) Who pays for it? Most obvious answer: Foundation. However there's
> currently a fairly clear line between the foundation website and the
> bitcoin.org website. I personally am fine with the bitcoin foundation
> funding the website, it's a lot closer to the bitcoin community than
> github. But some people might care. So next step would be to contact the
> Foundation board and see if they're willing to fund it.
>
> 2) Anti-DoS? I assume github handles this at the moment, though I doubt
> there's anything to be gained from DoSing the informational website
>
> 3) Where does the server go? Ideally, a hosting provider that accepts
> Bitcoin of course!
>
> 4) Who admins it?
>
> 5) Who controls DNS for it?
>
> Right now I think Sirius still owns DNS for bitcoin.org which is
> nonsense. He needs to pass it on to someone who is actually still involved
> with the project. Again, the most obvious neutral candidate would be the
> Foundation.
>
> So I think it's a good idea but there's a fair amount of work here. The
> primary upside I see is that it opens the potential for adding
> interactive/server-side code in future if we decide that would be useful.
>
>
>
> On Sun, Dec 8, 2013 at 8:25 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
>
>> On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula.org> wrote:
>> > BGP redirection is a reality and can be exploited without much
>>
>> You're managing to argue against SSL. Because it actually provides
>> basically protection against an attacker who can actively intercept
>> traffic to the server. Against that threat model SSL is clearly— based
>> on your comments— providing a false sense of security.
>>
>> We _do_ have protection that protect against that— the pgp signature,
>> but they are far from a solution since people do not check that.
>>
>> (I'm not suggesting we shouldn't have it, I'm suggesting you stop
>> arguing SSL provides protection it doesn't before you manage to change
>> my mind!)
>>
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4805 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

On 8 December 2013 19:25, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula.org> wrote:
> > BGP redirection is a reality and can be exploited without much
>
> You're managing to argue against SSL. Because it actually provides
> basically protection against an attacker who can actively intercept
> traffic to the server. Against that threat model SSL is clearly— based
> on your comments— providing a false sense of security.


Let me clarify. SSL renders BGP redirection useless because the browser
holds the signatures of CA's it trusts: an attacker cannot spoof a
certificate because it needs to be signed by a trusted CA: that's the point
of SSL, it encrypts and proves identity, the latter part is what thwarts
MITM. If there was an MITM the browser screams pretty loudly about it with
a big threat warning interstitial.

Regards,

Drak

[-- Attachment #2: Type: text/html, Size: 1360 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Sun, Dec 8, 2013 at 12:40 PM, Drak <drak@zikula.org> wrote:
> Let me clarify. SSL renders BGP redirection useless because the browser
> holds the signatures of CA's it trusts: an attacker cannot spoof a
> certificate because it needs to be signed by a trusted CA: that's the point
> of SSL, it encrypts and proves identity, the latter part is what thwarts
> MITM. If there was an MITM the browser screams pretty loudly about it with a
> big threat warning interstitial.

Sadly this isn't true: There are (many) CAs which will issue a
certificate (apparently sometime within minutes, though last
certificate I obtained took a couple hours total) to anyone who can
respond to http (not https) requests on behalf of the domain from the
perspective of the CA.

This means you can MITM the site, pass all traffic through except the
HTTP request from the CA, and start intercepting once the CA has
signed your certificate. This works because the CA does nothing to
verify identity except check that the requester can control the site.

If you'd like to me to demonstrate this attack for you I'd be willing—
I can provide a proxy that passes on :80 and :443, run your traffic
through it and I'll get a cert with your domain name.

I'm sorry for the tangent here— I think this sub-discussion is really
unrelated to having Bitcoin.org behind SSL— but "someone is wrong on
the internet", and its important to know that SSL hardly does anything
to reduce the need to check the offline signatures on the binaries.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 3152 bytes --]

On 8 December 2013 20:50, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> Sadly this isn't true: There are (many) CAs which will issue a
>  certificate (apparently sometime within minutes, though last
> certificate I obtained took a couple hours total) to anyone who can
> respond to http (not https) requests on behalf of the domain from the
> perspective of the CA.
>

Simple verification relies on being able to answer the email sent to the
person in the whois records, or standard admin/webmaster@ addresses to
prove ownership of the domain. This is a good point to note -
bitcoin.orgshould not get a simple certificate, but one that requires
identify
verification for the person/org who is applying. They are more expensive.


> This means you can MITM the site, pass all traffic through except the
> HTTP request from the CA, and start intercepting once the CA has
> signed your certificate. This works because the CA does nothing to
> verify identity except check that the requester can control the site.
>
> If you'd like to me to demonstrate this attack for you I'd be willing—
> I can provide a proxy that passes on :80 and :443, run your traffic
> through it and I'll get a cert with your domain name.
>

You cannot MITM SSL connections - it will cause a browser warning.
I do not have the means, but it has been demonstrated some people are
performing BGP redirections, daily, and on a massive scale... and it's a
problem, because BGP was designed on implicit trust.


> I'm sorry for the tangent here— I think this sub-discussion is really
> unrelated to having Bitcoin.org behind SSL— but "someone is wrong on
> the internet", and its important to know that SSL hardly does anything
> to reduce the need to check the offline signatures on the binaries.


You are right that the CA system is not full-proof, one CA was caught
issuing a bogus certificate on purpose a while back, I forgot the name but
it resulted in CA certificate revokation and the entire company being
blacklisted from Firefox and Google Chrome forever - basically a summary
corporate execution. I personally imagine the CIA or other state actor
could just quietly buy up an already trusted CA and abuse them. But it's
clear, people are watching, and if a CA is caught once, that's the end of
their business forever: Firefox and Google demonstrated that. The strategy
is possibly too expensive and risky to carry off which is maybe why they
don't do it.

What has been noted with all the Snowden leaks, and with the Lavabit case,
the security agencies did not get bogus certificates issued, they still got
court orders, or other deception to get hold of the encryption certificates
of their targets instead of issuing their own so they could listen in.

The CA system is not full proof, but it is what we have. Similar arguments
have been made against the use of identity certificates for bitcoin, but
that hasnt stopped it's inclusion in the bitcoin payment protocol.

Anyway, I take your points, but this is an area I am quite passionate about
so it's important for me to be clear.

Regards,

Drak

[-- Attachment #2: Type: text/html, Size: 4053 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Sun, Dec 8, 2013 at 1:07 PM, Drak <drak@zikula.org> wrote:
> Simple verification relies on being able to answer the email sent to the
> person in the whois records, or standard admin/webmaster@ addresses to prove
> ownership of the domain

Godaddy and many other CA's are verified from nothing other than a
http fetch, no email involved.

As I said, I'm willing to demonstrate if you have a domain.

> You cannot MITM SSL connections

You can, once you've obtained a certificate.

> Anyway, I take your points, but this is an area I am quite passionate about
> so it's important for me to be clear.

As I warned before, you're making my reconsider my position about the
downloads being SSL. If people are so convinced that SSL provides
protection it does not that even with an explanation and and an offer
to demonstrate then perhaps providing SSL will reduce people's
security.

... the _only_ reason I don't yet hold that position now is that I
know objectively that almost no one tests the signatures.

On Sun, Dec 8, 2013 at 1:11 PM, Drak <drak@zikula.org> wrote:
> It's not just about trust, there is the robustness factor: what if he
> becomes sick, unavailable, hit by a bus? Others need the ability to pickup
> and run with it. The control over the domain (including ability to renew
> registration, alter nameservers) needs to be with more than one person.
> That's why I suggest using the same people who have control over the
> software project at sf,github.

My understanding is that the domain is already controlled by more than
one person. You're not the first person to think of these things. :)

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Robert McKay]

On Sun, 8 Dec 2013 13:14:44 -0800, Gregory Maxwell wrote:
> On Sun, Dec 8, 2013 at 1:07 PM, Drak <drak@zikula.org> wrote:
>> Simple verification relies on being able to answer the email sent to 
>> the
>> person in the whois records, or standard admin/webmaster@ addresses 
>> to prove
>> ownership of the domain
>
> Godaddy and many other CA's are verified from nothing other than a
> http fetch, no email involved.

It's just as easy to steal emails via a BGP or DNS redirect anyway.. 
you could even take over the actual domain at the registry level by 
stealing a password reset via BGP or DNS redirect and actually many 
registries will hand over control of a domain by faxing them a forged 
driving license in the owner's name anyway so it doesn't even really 
need to be a particularly sophisticated attacker. Once you have registry 
control of the domain it's easy enough to get an SSL cert too, probably 
even an 'extended validation' one.

When Afghanistan was taken over the entire .af TLD was probably 
transferred using a forged fax to ICANN 
(http://web.archive.org/web/20041017031020/http://www.iana.org/cctld/af/razeeq-letter-13aug02.pdf) 
but I guess that's a little different :p

Rob

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Adam Back]

I think the one thing that SSL does provide is some protection against ARP
or DNS poisoning to trick the user into downloading from a different site.

The PGP WoT surrounding bitcoin or OS related ISOs be weak - I am not sure
if I could even check it directly myself despite spending a few hours
tracking down keys and checking fingerprints of biz cards of core devs I met
in person, then that is a relevant point.

Adam

On Sun, Dec 08, 2013 at 11:25:24AM -0800, Gregory Maxwell wrote:
>On Sun, Dec 8, 2013 at 11:16 AM, Drak <drak@zikula.org> wrote:
>> BGP redirection is a reality and can be exploited without much
>
>You're managing to argue against SSL. Because it actually provides
>basically protection against an attacker who can actively intercept
>traffic to the server. Against that threat model SSL is clearly— based
>on your comments— providing a false sense of security.
>
>We _do_ have protection that protect against that— the pgp signature,
>but they are far from a solution since people do not check that.
>
>(I'm not suggesting we shouldn't have it, I'm suggesting you stop
>arguing SSL provides protection it doesn't before you manage to change
>my mind!)
>
>------------------------------------------------------------------------------
>Sponsored by Intel(R) XDK
>Develop, test and display web and hybrid apps with a single code base.
>Download it for free now!
>http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

Has anyone seen the talk at 30c3 on the current NSA capabilities?
https://www.youtube.com/watch?v=b0w36GAyZIA

Specifically they are able to "beat the speed of light" between you and a
website such that if you communicate with Bob, they can sent competing
packets that will arrive before Bob's packets. They have  realtime deep
packet insertion able to inject arbitrary data into an TCP streams and can
change file downloads **on the fly**. This can be done remotely.

Sourceforge do not have https downloads, so this is yet another reason to
move downloads to somewhere that does - like github.
The NSA has the ability, right now to change every download of bitcoin-qt,
on the fly and the only cure is encryption.

Revealed as part of the presentation is the fact that if the NSA has access
to these capabilities, then so do others and in fact one of the things
revealed yesterday was independently discovered already and published.

Same goes for the bitcoin.org site - why are we dragging our feet on
installing an SSL certificate and redirecting all http to https? While no
solution is perfect, it's a lot better than zero defense.

You can see the irony of disseminating the bitcoin crypto-currency client
 in the clear.

For anyone who has not seen the video. You will be shocked by what is
actually in the wild being used today. It goes way beyond anything
imaginable even in science fiction.

https://www.youtube.com/watch?v=b0w36GAyZIA

Drak

[-- Attachment #2: Type: text/html, Size: 1901 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula.org> wrote:
> The NSA has the ability, right now to change every download of bitcoin-qt,
> on the fly and the only cure is encryption.

Please cut it out with the snake oil pedaling. This is really over the
top. You're invoking the NSA as the threat here? Okay. The NSA can
trivially compromise an HTTPS download site: even ignoring the CA
insecurity, and government run CAs certificate authorities issue CA
certs to random governments and corporations for dataloss prevention
purposes. Not to mention unparalleled access to exploits.

The downloads are protected by something far stronger than SSL
already, which might even have a chance against the NSA. Actual
signatures of the downloads with offline keys.

I'm all pro-SSL and all that, but you are— piece by piece— really
convincing me that it produces an entirely false sense of security
which is entirely unjustified.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]

Given that hardly anyone checks the signatures, it's fair to say downloads
aren't protected by anything at the moment. SSL for downloads can only
raise the bar, never lower it, and if the NSA want to kick off the process
of revoking some of the big CA's then I'm game (assuming anyone detects it
of course) :)

Anyway, nobody is dragging feet, the problem is right now we get what is
effectively a huge free subsidy from github and SourceForge for site
hosting. The cost is no SSL. So getting SSL would require that "we" pay for
it ourselves, but the primary method we have for funding public
goods/infrastructure (the Foundation) which is the subject of various
conspiracy theories. Jeremy has made a generous offer further up the
thread, the issue being I guess none of us know how much traffic we
actually get :( I remember suggesting that we whack Google Analytics or
some other statistics package on when the new website design was done and
that was rejected for similar reasons ("organisations are bad").

So we are in a position where we get a subsidy of large but unknown size
from various existing US corporations, but moving to different ones is
controversial, hence no progress :)



On Tue, Dec 31, 2013 at 1:48 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula.org> wrote:
> > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > on the fly and the only cure is encryption.
>
> Please cut it out with the snake oil pedaling. This is really over the
> top. You're invoking the NSA as the threat here? Okay. The NSA can
> trivially compromise an HTTPS download site: even ignoring the CA
> insecurity, and government run CAs certificate authorities issue CA
> certs to random governments and corporations for dataloss prevention
> purposes. Not to mention unparalleled access to exploits.
>
> The downloads are protected by something far stronger than SSL
> already, which might even have a chance against the NSA. Actual
> signatures of the downloads with offline keys.
>
> I'm all pro-SSL and all that, but you are— piece by piece— really
> convincing me that it produces an entirely false sense of security
> which is entirely unjustified.
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3801 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Tue, Dec 31, 2013 at 5:59 AM, Mike Hearn <mike@plan99.net> wrote:
> but moving to different ones is
> controversial, hence no progress :)

The site was actually moved onto a dedicated server temporarily and it
melted down under the load. I wouldn't call that no progress.


Perhaps I wasn't clear on the point I was making Drak's threat model
is not improved in the slightest by SSL. It would be improved by
increasing the use of signature checking, e.g. by making it easier.
Flat out misinformation never improves security.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

>
> The site was actually moved onto a dedicated server temporarily and it
> melted down under the load. I wouldn't call that no progress.
>

Oh, it did? When was that? I must have missed this excitement :)

Any idea how much load it had?

Perhaps I wasn't clear on the point I was making Drak's threat model
> is not improved in the slightest by SSL. It would be improved by
> increasing the use of signature checking, e.g. by making it easier.
>

Well, that depends. If you watch Applebaums talk he is pushing TLS pretty
hard, and saying that based on the access to the source docs some of their
MITM attacks can't beat TLS. It appears that they have the capability to do
bulk MITM and rewrite of downloads as Drak says but *not* when TLS is
present, that would force more targeted attacks. So to me that implies that
TLS does raise the bar and is worth doing.

However if we can't find a server that won't melt under the load, then
that'd be an issue. We could consider hosting downloads on AppEngine or
something else that can handle both high load and TLS.

[-- Attachment #2: Type: text/html, Size: 1532 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Jeremy Spilman]

[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]

I didn't know about the dedicated server meltdown, it wasn't any of my  
infra. Anyway, my previous offer still stands.

One less 'security theater' approach would be if we could provide  
forward-validation of updates using the blockchain. It's always going to  
be up to the user the first time they install the wallet to verify the  
provenance of the binaries/source. From that point forward, we could make  
it easier if the wallet could detect updates and prove they were valid.

This could be as simple as hard-coding a public key into the client and  
checking a signature on the new binaries. But it could also be more  
interesting...

For example, a well known address on the blockchain corresponds to  
multi-sig with keys controlled by developers (or whatever key policy the  
release team wants to impose). A spend from that address announces a new  
release, and includes the expected hash of the file.

You would probably need some way to handle the different release targets.  
A more rigorous approach could identify all the various releases in terms  
of a BIP32 xpubkey whose branches would correspond to the different  
release trains and platform builds. Spends from a node announce the  
release and the expected hash.

This provides zero benefit if the wallet software is already compromised,  
but I think this would allow trusted automatic update notification, and a  
trusted way to deliver the expected hashes. It also might resolve some of  
the consternation around when a release is truly "released", if that's  
really a problem.

I'm not sure how far along the slope you would want to go; 1) announcing  
updates in the UI, 2) providing a button the user could click to verify a  
binary matches its expected hash, 3) click to download and verify the  
upgrade matches the expected hash, 4) click to upgrade

Formalizing the release process around a set of privkeys (or split shares  
of keys) may raise its own set of questions.

For the download itself, I've heard the advocates of announcing  
availability on the blockchain leading to a BitTorrent magnet link, but I  
also understand objections to adding an entire BitTorrent stack into a  
wallet.

On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99.net> wrote:

>> The site was actually moved onto a dedicated server temporarily and it
>> melted down under the load. I wouldn't call that no progress.
>
> Oh, it did? When was that? I must have missed this excitement :)
>Any idea how much load it had?
>
>> Perhaps I wasn't clear on the point I was making Drak's threat model
>> is not improved in the slightest by SSL. It would be improved by
>> increasing the use of signature checking, e.g. by making it easier.
>
> Well, that depends. If you watch Applebaums talk he is pushing TLS  
> pretty hard, and saying that based on the access to the source docs some  
> of >their MITM attacks can't beat TLS. It appears that they have the  
> capability to do bulk MITM and rewrite of downloads as Drak says but  
> *not* when >TLS is present, that would force more targeted attacks. So  
> to me that implies that TLS does raise the bar and is worth doing.
>
> However if we can't find a server that won't melt under the load, then  
> that'd be an issue. We could consider hosting downloads on AppEngine or  
> >something else that can handle both high load and TLS.

[-- Attachment #2.1: Type: text/html, Size: 4217 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 4621 bytes --]

We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads.

Jeremy Spilman <jeremy@taplink.co> wrote:
>I didn't know about the dedicated server meltdown, it wasn't any of my 
>
>infra. Anyway, my previous offer still stands.
>
>One less 'security theater' approach would be if we could provide  
>forward-validation of updates using the blockchain. It's always going
>to  
>be up to the user the first time they install the wallet to verify the 
>
>provenance of the binaries/source. From that point forward, we could
>make  
>it easier if the wallet could detect updates and prove they were valid.
>
>This could be as simple as hard-coding a public key into the client and
> 
>checking a signature on the new binaries. But it could also be more  
>interesting...
>
>For example, a well known address on the blockchain corresponds to  
>multi-sig with keys controlled by developers (or whatever key policy
>the  
>release team wants to impose). A spend from that address announces a
>new  
>release, and includes the expected hash of the file.
>
>You would probably need some way to handle the different release
>targets.  
>A more rigorous approach could identify all the various releases in
>terms  
>of a BIP32 xpubkey whose branches would correspond to the different  
>release trains and platform builds. Spends from a node announce the  
>release and the expected hash.
>
>This provides zero benefit if the wallet software is already
>compromised,  
>but I think this would allow trusted automatic update notification, and
>a  
>trusted way to deliver the expected hashes. It also might resolve some
>of  
>the consternation around when a release is truly "released", if that's 
>
>really a problem.
>
>I'm not sure how far along the slope you would want to go; 1)
>announcing  
>updates in the UI, 2) providing a button the user could click to verify
>a  
>binary matches its expected hash, 3) click to download and verify the  
>upgrade matches the expected hash, 4) click to upgrade
>
>Formalizing the release process around a set of privkeys (or split
>shares  
>of keys) may raise its own set of questions.
>
>For the download itself, I've heard the advocates of announcing  
>availability on the blockchain leading to a BitTorrent magnet link, but
>I  
>also understand objections to adding an entire BitTorrent stack into a 
>
>wallet.
>
>On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99.net> wrote:
>
>>> The site was actually moved onto a dedicated server temporarily and
>it
>>> melted down under the load. I wouldn't call that no progress.
>>
>> Oh, it did? When was that? I must have missed this excitement :)
>>Any idea how much load it had?
>>
>>> Perhaps I wasn't clear on the point I was making Drak's threat model
>>> is not improved in the slightest by SSL. It would be improved by
>>> increasing the use of signature checking, e.g. by making it easier.
>>
>> Well, that depends. If you watch Applebaums talk he is pushing TLS  
>> pretty hard, and saying that based on the access to the source docs
>some  
>> of >their MITM attacks can't beat TLS. It appears that they have the 
>
>> capability to do bulk MITM and rewrite of downloads as Drak says but 
>
>> *not* when >TLS is present, that would force more targeted attacks.
>So  
>> to me that implies that TLS does raise the bar and is worth doing.
>>
>> However if we can't find a server that won't melt under the load,
>then  
>> that'd be an issue. We could consider hosting downloads on AppEngine
>or  
>> >something else that can handle both high load and TLS.
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>
>organizations don't have a clear picture of how application performance
>
>affects their revenue. With AppDynamics, you get 100% visibility into
>your 
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 5679 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Jeremy Spilman]

So I looked into gitian, the first thing I noticed was the hashes that  
people were signing, for example:

    https://github.com/bitcoin/gitian.sigs/blob/master/0.8.6-win32/gavinandresen/bitcoin-build.assert

don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually  
hosted by sourceforce. That was a bit alarming at first, but I talked to  
BlueMatt and maaku on IRC and the difference is due to Gavin Authenticode  
signing the executable for windows.

BlueMatt asked if someone could implement in gitian-downloader a way to  
strip off the signature so that we could get back to the raw binary with a  
hash that matches what everyone is producing from gitian.  I found:

   http://blog.didierstevens.com/programs/disitool/

which is a Python script which can strip the signature nicely, but the  
hashes still don't match.

I couldn't find a gitian build of 0.8.6 so I built my own, and after  
verifying the hash for v0.8.6 was '49547ff9...' as expected I looked at  
the hex diff between that and the sig-stripped .exe from sourceforge, and  
the only two differences are:

   - At offset D8 the stripped file has '5D E2 B2' versus 'F9 F4 00' in the  
gitian build
   - The sig-stripped file has an extra byte '00' at the end

I started to look at the file spec for windows PE files and quickly  
thought better of it. Maybe someone better informed can chime in on what  
those three bytes at offset D8 specify.

I'm not sure if we want to patch the signature onto the gitian build, or  
strip the signature off of the Gavin-signed build, but something of the  
sort is necessary if you want get gitian-downloader to match the official  
distro (for Windows at least).

In any case, I think wallet users want to know when an upgrade is  
available, and ability to click an 'update' button get a binary they can  
trust. It's not a problem unique to bitcoind, deterministic builds are  
awesome, but I don't think fully solve it.

Thanks,
Jeremy

On Tue, 31 Dec 2013 13:33:54 -0800, Matt Corallo  
<bitcoin-list@bluematt.me> wrote:

> We already have a wonderful system for secure updating -  
> gitian-downloader. We just neither use it >not bother making actual  
> gitian releases so anyone can use it to verify signatures of downloads.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

>
> In any case, I think wallet users want to know when an upgrade is
> available, and ability to click an 'update' button get a binary they can
> trust. It's not a problem unique to bitcoind, deterministic builds are
> awesome, but I don't think fully solve it.
>

Deterministic builds are one part of the equation. Matt Corallo actually
did implement auto-updating using gitian updater:
https://github.com/bitcoin/bitcoin/pull/1453

It ran into lots of bike shedding and was eventually abandoned, but there
is no question whether it is possible with the current build process.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1034 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

That seems overly complicated, there's no need for the Bitcoin protocol to
be involved. Deterministic builds with threshold signed updates are a
problem the entire crypto community is now interested in solving - any
solution should be generic.

Really all you need is an update engine that allows a CHECKMULTISIG type
approach. When the update engine is not under our control, i.e. on Android,
Shoup style RSA threshold signatures can potentially work (though I must
admit, I have never found time to play with the implementation I have for
that algorithm).



On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman <jeremy@taplink.co> wrote:

>  I didn't know about the dedicated server meltdown, it wasn't any of my
> infra. Anyway, my previous offer still stands.
>
> One less 'security theater' approach would be if we could provide
> forward-validation of updates using the blockchain. It's always going to be
> up to the user the first time they install the wallet to verify the
> provenance of the binaries/source. From that point forward, we could make
> it easier if the wallet could detect updates and prove they were valid.
>
> This could be as simple as hard-coding a public key into the client and
> checking a signature on the new binaries. But it could also be more
> interesting...
>
> For example, a well known address on the blockchain corresponds to
> multi-sig with keys controlled by developers (or whatever key policy the
> release team wants to impose). A spend from that address announces a new
> release, and includes the expected hash of the file.
>
> You would probably need some way to handle the different release targets.
> A more rigorous approach could identify all the various releases in terms
> of a BIP32 xpubkey whose branches would correspond to the different release
> trains and platform builds. Spends from a node announce the release and the
> expected hash.
>
> This provides zero benefit if the wallet software is already compromised,
> but I think this would allow trusted automatic update notification, and a
> trusted way to deliver the expected hashes. It also might resolve some of
> the consternation around when a release is truly "released", if that's
> really a problem.
>
> I'm not sure how far along the slope you would want to go; 1) announcing
> updates in the UI, 2) providing a button the user could click to verify a
> binary matches its expected hash, 3) click to download and verify the
> upgrade matches the expected hash, 4) click to upgrade
>
> Formalizing the release process around a set of privkeys (or split shares
> of keys) may raise its own set of questions.
>
> For the download itself, I've heard the advocates of announcing
> availability on the blockchain leading to a BitTorrent magnet link, but I
> also understand objections to adding an entire BitTorrent stack into a
> wallet.
>
> On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99.net> wrote:
>
> The site was actually moved onto a dedicated server temporarily and it
>> melted down under the load. I wouldn't call that no progress.
>>
>
> Oh, it did? When was that? I must have missed this excitement :)
>
> Any idea how much load it had?
>
> Perhaps I wasn't clear on the point I was making Drak's threat model
>> is not improved in the slightest by SSL. It would be improved by
>> increasing the use of signature checking, e.g. by making it easier.
>>
>
> Well, that depends. If you watch Applebaums talk he is pushing TLS pretty
> hard, and saying that based on the access to the source docs some of their
> MITM attacks can't beat TLS. It appears that they have the capability to do
> bulk MITM and rewrite of downloads as Drak says but *not* when TLS is
> present, that would force more targeted attacks. So to me that implies that
> TLS does raise the bar and is worth doing.
>
> However if we can't find a server that won't melt under the load, then
> that'd be an issue. We could consider hosting downloads on AppEngine or
> something else that can handle both high load and TLS.
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 5246 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

>
> Oh, it did? When was that? I must have missed this excitement :)
>>
>
I would be very interested to learn more about this. It seems the steady
state load on the site is not very high:

https://github.com/bitcoin/bitcoin.org/pull/287

(Saivann ran Google Analytics on the site for a little while to get traffic
figures). Peak of 10 visitors per second, assume a 10x blowup on resources,
that's only ~100 reqs/sec steady state, that shouldn't strain any kind of
reasonable server. So perhaps the specs of the dedicated server were not
what you might imagine.

Perhaps we should move the site over to Jeremy's hosting? It shouldn't be
very expensive to serve outside of major press cycles. Once that is done,
perhaps we can find/blag some SSL-protected file hosting.

[-- Attachment #2: Type: text/html, Size: 1534 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Jorge Timón]

On 12/31/13, Mike Hearn <mike@plan99.net> wrote:
>  remember suggesting that we whack Google Analytics or
> some other statistics package on when the new website design was done and
> that was rejected for similar reasons ("organisations are bad").

Analytics software would be useful. I suggest using Piwik or another
free software alternative instead of Google's package.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Benjamin Cordes]

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

Interesting. I think the original BitDNS discussion was more interesting
that what currently is happening with namecoin, see
https://bitcointalk.org/index.php?topic=1790.0

Satoshi said there: "1) IP records don't need to be in the chain, just do
registrar function not DNS.  And CA problem solved, neat."

Besides, ICANN is currently selling out the global public namespace - not
that anybody really cares about such measly topics as the ownership of
global namespaces. And so some guy on the Cayman Islands is now the largest
holder of TLD's.

On Tue, Dec 31, 2013 at 2:48 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula.org> wrote:
> > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > on the fly and the only cure is encryption.
>
> Please cut it out with the snake oil pedaling. This is really over the
> top. You're invoking the NSA as the threat here? Okay. The NSA can
> trivially compromise an HTTPS download site: even ignoring the CA
> insecurity, and government run CAs certificate authorities issue CA
> certs to random governments and corporations for dataloss prevention
> purposes. Not to mention unparalleled access to exploits.
>
> The downloads are protected by something far stronger than SSL
> already, which might even have a chance against the NSA. Actual
> signatures of the downloads with offline keys.
>
> I'm all pro-SSL and all that, but you are— piece by piece— really
> convincing me that it produces an entirely false sense of security
> which is entirely unjustified.
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3111 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Troy Benjegerdes]

On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula.org> wrote:
> > The NSA has the ability, right now to change every download of bitcoin-qt,
> > on the fly and the only cure is encryption.

No, the only cure is the check the hashes. We should know something
about hashes here. TLS is a big pile of 'too big to audit'. Spend
a couple of satoshis and put the hash of the source tar.gz and the
binaries in the blockchain. Problem solved.

<snipped>

> The downloads are protected by something far stronger than SSL
> already, which might even have a chance against the NSA. Actual
> signatures of the downloads with offline keys.
> 
> I'm all pro-SSL and all that, but you are— piece by piece— really
> convincing me that it produces an entirely false sense of security
> which is entirely unjustified.

I used to think encryption was important, and this exchange convinced
me that kerberized telnet with no encryption but with integrity
checking would be far more secure than 'secure' shell.

Also, there's some organization that's inserting malicious memes
that try to get me to buy shit below my signature. How about we 
move the mailing list? I've run mailman servers before, and there's
also http://savannah.gnu.org/maintenance/WhyChooseSavannah/

-- Troy (da hozer)

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On 3 January 2014 05:45, Troy Benjegerdes <hozer@hozed.org> wrote:

> On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula.org> wrote:
> > > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > > on the fly and the only cure is encryption.
>
> No, the only cure is the check the hashes. We should know something
> about hashes here. TLS is a big pile of 'too big to audit'. Spend
> a couple of satoshis and put the hash of the source tar.gz and the
> binaries in the blockchain. Problem solved.


Which is why, as pointed out several times at 30c3 by several renowned
figures, why cryptography has remained squarely outside of mainstream use.
It needs to just work and until you can trust the connection and what the
end point sends you, automatically, it's a big fail and the attack vectors
are many.

<sarcasm>I can just see my mother or grandma manually checking the hash of
a download... </sarcasm>

Drak

[-- Attachment #2: Type: text/html, Size: 1501 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Fri, Jan 3, 2014 at 9:59 AM, Drak <drak@zikula.org> wrote:

> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, automatically, it's a big fail and the attack vectors
> are many.
>
> <sarcasm>I can just see my mother or grandma manually checking the hash of
> a download... </sarcasm>
>

Maybe a simple compromise would be to add a secure downloader to the
bitcoin client.

The download link could point to a meta-data file that has info on the
download.

file_url=
hash_url=
sig_url=
message=This is version x.y.z of the bitcoin client

It still suffers from the root CA problem though.  The bitcoin client would
accept Gavin's signature or a "core team" signature.

At least it would provide forward security.

It could also be used to download files for different projects, with
explicit warnings that you are adding a new trusted key.

When you try to download, you would be given a window

Project: Some Alternative Wallet
Signed by: P. Lead
Message:

Confirm download Yes No

However, even if you do that, each trusted key is only linked to a
particular project.

It would say if the project and/or leader is unknown.

[-- Attachment #2: Type: text/html, Size: 2358 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Adam Back]

You know if you want to make some form of investment, you might like make an
attempt to look them up on the internet, check the phone number in a phone
book or directory enquiries, look for references and reviews?

So it is with the hash of the binary you are about to trust with your
investment funds.  I dont think its such a difficult question.  Ask your
more technical friends to confirm this hash is correct.

Its interesting that hashes are more trustworthy than signatures, since all
the NSLs and backdoors, its hard to trust a signature.

I have the same problem with linux distros that want to install hundreds of
components downloaded over the internet, based on signatures.  I would far
rather a merkle hash of the distribution at that point in time, which
authenticates directly any of the optional downloadable components.

(Or better yet a distro that like comes on a CD and doesnt download
anything...  Amazing how most CD and even DVD iso images immediately
download stupid things like fonts???  What were they thinking?  I downloaded
fedora > 4GB of stuff and they need to download a font just to get past step
2 of the installer?  Thats a sensless, retrograde, selective backdoor
opportunity.)

Adam

On Fri, Jan 03, 2014 at 11:22:35AM +0000, Tier Nolan wrote:
>   On Fri, Jan 3, 2014 at 9:59 AM, Drak <[1]drak@zikula.org> wrote:
>
>   Which is why, as pointed out several times at 30c3 by several renowned
>   figures, why cryptography has remained squarely outside of mainstream
>   use. It needs to just work and until you can trust the connection and
>   what the end point sends you, automatically, it's a big fail and the
>   attack vectors are many.
>   <sarcasm>I can just see my mother or grandma manually checking the hash
>   of a download... </sarcasm>
>
>   Maybe a simple compromise would be to add a secure downloader to the
>   bitcoin client.
>   The download link could point to a meta-data file that has info on the
>   download.
>   file_url=
>   hash_url=
>   sig_url=
>   message=This is version x.y.z of the bitcoin client
>   It still suffers from the root CA problem though.  The bitcoin client
>   would accept Gavin's signature or a "core team" signature.
>   At least it would provide forward security.
>   It could also be used to download files for different projects, with
>   explicit warnings that you are adding a new trusted key.
>   When you try to download, you would be given a window
>   Project: Some Alternative Wallet
>   Signed by: P. Lead
>   Message:
>   Confirm download Yes No
>   However, even if you do that, each trusted key is only linked to a
>   particular project.
>   It would say if the project and/or leader is unknown.
>
>References
>
>   1. mailto:drak@zikula.org

>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>organizations don't have a clear picture of how application performance
>affects their revenue. With AppDynamics, you get 100% visibility into your
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Troy Benjegerdes]

On Fri, Jan 03, 2014 at 09:59:15AM +0000, Drak wrote:
> On 3 January 2014 05:45, Troy Benjegerdes <hozer@hozed.org> wrote:
> 
> > On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > > On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak@zikula.org> wrote:
> > > > The NSA has the ability, right now to change every download of
> > bitcoin-qt,
> > > > on the fly and the only cure is encryption.
> >
> > No, the only cure is the check the hashes. We should know something
> > about hashes here. TLS is a big pile of 'too big to audit'. Spend
> > a couple of satoshis and put the hash of the source tar.gz and the
> > binaries in the blockchain. Problem solved.
> 
> 
> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, automatically, it's a big fail and the attack vectors
> are many.
> 
> <sarcasm>I can just see my mother or grandma manually checking the hash of
> a download... </sarcasm>

'make' should check the hash. The binary should check it's own hash. The
operating system should check the hash.

How about if I sell your Grandma an android table loaded only with free 
software, and use the existing infrastructure android provides to only
allow software to be installed that can be integrity-verified from a 
public key that can be downloaded from the blockchain?

Would you pay $50 (or 2 litecoin) more for at tablet with free software
that protects you and your grandma's interests, rather than selling them
to google/apple/microsoft?

I'm working on eventually being able to build hardware for which the 
entire design specifications, from case to cpu core verilog, all they way
up to the pre-installed cryptographic currency wallet(s) are all signed
and released as part of the Debian archive. 

But I need people like you to explain to your Grandma why this hardware
costs more than hardware that monetizes eyeballs and sells your private
information to the highest bidder.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Jorge Timón]

On 1/3/14, Troy Benjegerdes <hozer@hozed.org> wrote:
> 'make' should check the hash.

An attacker could replace that part of the makefile.
Anyway, I think this is more oriented for compiled binaries, not for
people downloading the sources. I assume most of that people just use
git.

> The binary should check it's own hash.

I'm afraid this is not possible.

> The operating system should check the hash.

There's package management systems like apt-secure that do exactly this.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Troy Benjegerdes]

On Fri, Jan 03, 2014 at 07:21:17PM +0100, Jorge Timón wrote:
> On 1/3/14, Troy Benjegerdes <hozer@hozed.org> wrote:
> > 'make' should check the hash.
> 
> An attacker could replace that part of the makefile.
> Anyway, I think this is more oriented for compiled binaries, not for
> people downloading the sources. I assume most of that people just use
> git.
> 
> > The binary should check it's own hash.
> 
> I'm afraid this is not possible.
>
> > The operating system should check the hash.
> 
> There's package management systems like apt-secure that do exactly this.

Yes. Promoting operating systems (and signed .deb packages) is a far better
thing to do than worrying about TLS on the bitcoin.org server.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Drak]

[-- Attachment #1: Type: text/plain, Size: 4489 bytes --]

There is really no excuse for not using an SSL certificate. Without one it
would be trivial for an attacker to change the contents of the page via
MITM.
Recent studies have shown MASSIVE abuse of the BGP routing protocol being
used to redirect websites through a third party.
This is not a theoretical attack, it's happening every single day on a
global scale and could be used to divert users to a rogue versions of
software.
It's just a matter of time... it will happen sooner or later given the
incentives it could bring...

Recent references:
http://www.theregister.co.uk/2013/11/22/net_traffic_redirection_attacks/
http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/

The only way to mitigate these MITMs is to use SSL.

Also it's about time we hosted the Bitcoin Qt software at Github. They have
a releases feature where you can upload a packaged release (see
https://github.com/blog/1547-release-your-software). There are also no
adverts (another privacy leak at the least) and many feel are more
trustworthy than Sourceforge: it also makes sense to have the downloads
where the source is developed.

Regards,

Drak



On 8 December 2013 03:38, Odinn Cyberguerrilla <
odinn.cyberguerrilla@riseup.net> wrote:

> Hello, re. the dedicated server for bitcoin.org idea, I have a few
> thoughts
>
> 1) I have commented in a blogpost of August 2013 at
> https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
> issues with CA related to bitcoin.org - where I mentioned something
> relative to the DigiCert certificate,
> "DigiCert “may revoke a Certificate, without notice, for the reasons
> stated in the CPS, including if DigiCert reasonably believes that” (…)
> “Applicant is added to a government list of prohibited persons or entities
> or is operating from a prohibited destination under the laws of the United
> States” (…) “the Private Key associated with a Certificate was disclosed
> or Compromised”"
> In the same post I mentioned
> "Bitcoin.org has no certificate, no encryption — a situation which has its
> own obvious problems. Bitcoin.org currently sends users to download the
> bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
> certificate based on GeoTrust:
> https://www.geotrust.com/resources/repository/legal/"
>
> (Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
> encrypted' examining it in a cursory fashion w/ Chrome)
>
> Not sure how this would work, but it would be nice to see the content at
> bitcoin.org encrypted, of course, but also further decentralized? how many
> mirrors are there of bitcoin.org - not sure, but a few things that come to
> mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
> There are many ways to decentralize something but that is just something
> that comes to mind.
>
> This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
> ('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
> https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
> of certain content
>
> Some things to think about.
>
> > I would like to know what are your thoughts on moving bitcoin.org on a
> > dedicated server with a SSL certificate?
> >
> > I am considering the idea more seriously, but I'd like some feedback
> > before taking steps.
> >
> > Saïvann
> >
> >
> ------------------------------------------------------------------------------
> > Sponsored by Intel(R) XDK
> > Develop, test and display web and hybrid apps with a single code base.
> > Download it for free now!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 6648 bytes --]

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Luke-Jr]

On Sunday, December 08, 2013 10:00:35 AM Drak wrote:
> Also it's about time we hosted the Bitcoin Qt software at Github. They have
> a releases feature where you can upload a packaged release (see
> https://github.com/blog/1547-release-your-software). There are also no
> adverts (another privacy leak at the least) and many feel are more
> trustworthy than Sourceforge: it also makes sense to have the downloads
> where the source is developed.

I'm not aware of any rational basis for trusting GitHub more than SourceForge. 
At least SourceForge is transparent and releases their source code.

Luke

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Gregory Maxwell]

On Sun, Dec 8, 2013 at 2:00 AM, Drak <drak@zikula.org> wrote:
> There is really no excuse for not using an SSL certificate. Without one it
> would be trivial for an attacker to change the contents of the page via
> MITM.

Having control of the site gives you a cert regardless, as several CAs
will issue a cert to anyone who can make a http page appear at a
specific URL at the domain when requested via the CA over http.

It really is darn near pretextual security in this kind case— only
protecting you against attacks near the client, not the server— but as
Wladimir says, it's expected and I don't see how it would be a harm.

The revocation argument is somewhat interesting, especially since any
such site should use HSTS or otherwise a downgrade attack is trivial.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

On Sun, Dec 8, 2013 at 2:17 AM, Saïvann Carignan <saivann@gmail.com> wrote:

> I would like to know what are your thoughts on moving bitcoin.org on a
> dedicated server with a SSL certificate?
>

Good idea.
If anything, these days, not using https is sort of a smell for sites that
security is not being taken seriously.

Wladimir

[-- Attachment #2: Type: text/html, Size: 738 bytes --]