<sprin>
I've got the changes for #1202 ready on a branch. The commits have all been rewritten to some degree, so is it better to 'force push' to the branch the PR is tracking, or open a new PR?
<sprin>
also, I seem to remember discussion of using letsencrypt to get grain subdomain certificates on the fly (#1593)
<asheesh>
The main downsides are (why can't I find this summarized anywhere? I still need to write that)
<asheesh>
- certificate hostnames are published immediately, so the use of session subdomains as last-ditch CSRF tokens is broken due to them not being secret
<asheesh>
- it's one per user session to each grain -- seems like a lot of load, and would be a new remote service on the critical path of every user session
<asheesh>
However, this is still a serious obstacle for people, so I wish we had a better solution.
<sprin>
with respect to 2, what about pre-fetching some number of certs before grains are started?
<asheesh>
Could work, though someone should do the math to figure out how many are plausibly needed per unit time.
<sprin>
and with regards o #1... yes, I see the security implication here.
<asheesh>
Let's Encrypt does support SAN certificates, so if we fetch like 100 per hour or something, then we could add a self-defense thing where most of them are honeypot hostnames (??)
<asheesh>
I'm torn because I'm extremely sympathetic to anything that make Sandstorm easier to use or install, even at the cost of making it less secure, but then I think about it and wonder if that's actually reasonable.
<asheesh>
FWIW static publishing doesn't need wildcards, and could be Let's Encrypt'd, except maybe not given some details of our GlobalSign contract that are somewhat hazy, so I can take a TODO item to figure that out.
<joeyh>
asheesh: been lurking for some time, and I played with sandstorm at spinachcon!
<asheesh>
Ooh!
<sprin>
With regards to the CSRF protection of the random subdomains, if we can agree that it is security by obscurity, perhaps we can retain the security properties in a different way
<asheesh>
It's supposed to be security-by-cryptographically-random-unguessable-token which is (as far as I know) different from security-by-obscurity but the difference is subtle.
<asheesh>
We could put things like that into the path, but then that'd break a bunch of apps probably.
<asheesh>
It's all within the grain-frame URL so URL ugliness doesn't necessarily affect the user directly.
<asheesh>
The other aspect is that we like that each session is on its own origin, so in terms of cookies and other things, grains definitely can't read each others' data.
<asheesh>
That could be solved by N*M subdomains that *don't* change, where N=num users, M=num grains
<asheesh>
(Because then each user+grain is on its own subdomain, which is the actual security boundary)
sprin_ has joined #sandstorm
<dwrensha>
I'm curious what bothers most people about needing a wildcard cert. Is it the cost? is it a philosophical thing? or is it that it's not feasible in some environments?
<sprin_>
it is the cost.
<asheesh>
For wildcard DNS, It's not feasible in corporate DNS environments often, fwiw, where for a non-wildcard hostname you have to ask IT and they will glare at you, but for a non-wildcard hostname you automatically get it with your DHCP lease.
<sprin_>
One reason I am currently interested into sandstorm is to be able to assist organizations with zero budget for IT
<asheesh>
wildcard DNS != wildcard cert, but related, so thought I'd mention
sprin has quit [Ping timeout: 240 seconds]
<dwrensha>
sprin_: but if there's zero budget, what about hosting costs for the Sandstorm server?
<sprin_>
yes, that is difficult. I have thought of setting up a shared fund which can pay it
<asheesh>
FWIW there are probably hosting providers that will donate VMs for that, e.g. gandi.net has donated a VM to freeculture.org (a student advocacy for digital civil rights organization I've been a part of over the years).
<asheesh>
If you need help finding people to donate that, let me know sprin_ : ) but I know it doesn't help with wildcard cert.
<sprin_>
average annual hosting cost per org could be as little as $60, so a $100 cert is still a big expense
<sprin_>
Very nice. Yes, $5/mo/1GB is just what I currently pay for my own VMs from a big name cloud provider
sprin_ is now known as sprin
<asheesh>
For storm.debian.net I pay $60/mo for my wildcard cert, but it's still quite something, and the renewal flow is still hard to remember to do yearly.
<asheesh>
(I'm a co-maintainer of storm.debian.net, as a volunteer/hobby/sideproject not an official Sandstorm activity)
<sprin>
neat!
<sprin>
asheesh, missed your comments re: security by obscurity due to a connection drop
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<sprin>
the hostname (grain subdomain) is logged by any number of intermediate routers, right? so to me, the token does not need to be guessed by an attacker
<sprin>
only attackers who cannot see any traffic between client and sandstorm are foiled
mnutt has joined #sandstorm
<asheesh>
Yeah, which is IMHO most attackers, but yeah, it's far from perfect.
<sprin>
I have to think about it a bit more, but it seems that randomly selecting a subdomain/cert from a large pool at the time of session creation might offer a similar level of protection
<asheesh>
One situation where it doesn't provide a similar level of protection is if the attacker has a list of subdomains; if so, then the attacker can iterate across them.
<sprin>
so the attack would iterate across a large list of subdomains, with a CSRF attack crafted for some particular app, expecting that at least one of the subdomains would be associated with an active session for that app?
<asheesh>
Yeah, that'd be the way I'd do it.
<asheesh>
BTW I asked Jenkins to restart so it's presumably doing that so that's why it's down presumably.
<sprin>
Hmm, it seems like a lot of work on behalf of the attacker. about the same amount of work as to gain the capability to observe the traffic of a specific user.
<sprin>
I guess I am biased against protections that rely on trusting that info sent in the clear won't be observed by an attacker.
<sprin>
And with SNI, hostname is in the clear
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
bony has quit [Ping timeout: 272 seconds]
jadewang has joined #sandstorm
bony has joined #sandstorm
bony has quit [Changing host]
bony has joined #sandstorm
* asheesh
waves to any new people here
<sprin>
asheesh: question with respect to updating a PR - I have a different branch with a new set of commits. Some history will be lost if I force-update the branch the PR tracks with a new set of commits. What should I do?
<dwrensha>
I believe github is somewhat better than it used to be about throwing away comments on rebased commits?
<sprin>
OK, let's give it a try ;) It's incredible that it lost comments in the first place...
jadewang has quit [Remote host closed the connection]
<sprin>
Ah, I see... it did rewrite the thread a bit, but at least comments on the old commits are preserved as "so-and-so commented on an outdated diff"
<sprin>
@mnutt: the PR for #1202 is updated, and now includes X-OC-MTime header in the response whitelist
<mnutt>
sprin: awesome, thanks for letting me know! I'll check it out tonight
afuentes has quit [Quit: Leaving]
jadewang has joined #sandstorm
jemc has quit [Ping timeout: 264 seconds]
afuentes has joined #sandstorm
xet7_ has quit [Remote host closed the connection]
xet7_ has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jemc has joined #sandstorm
sydney_untangle has quit [Read error: Connection reset by peer]
sydney_untangle has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
theSoenke has joined #sandstorm
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]