17:59:43 <gaba> #startmeeting Tor Browser release meeting, July 21st 2020
17:59:43 <MeetBot> Meeting started Tue Jul 21 17:59:43 2020 UTC.  The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:44 <gaba> hi!
17:59:48 <gaba> pad here: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-browser-release-meeting-keep
18:00:06 <gaba> Add anything to the agenda in line 30
18:00:49 <sysrqb> o/
18:00:51 <antonela> hello
18:01:36 <GeKo> o/
18:03:19 <sysrqb> i see only one discussion item today :)
18:03:31 <gaba> next release date is next week. Do we have anything else other that the assumptions about the active conenction with HS?
18:03:34 <gaba> yes
18:05:51 <gaba> so, sysrqb: you want to follow the discussion from yesterday?
18:06:18 <sysrqb> sure
18:06:49 <sysrqb> GeKo recommended we gain more insight into how onion services are currently deployed
18:07:04 <sysrqb> and we should talk with other onoin service operators about this situation
18:07:27 <sysrqb> i didn't know how i should do that, so i decided i'd just send an email to tor-project@ and ask
18:08:01 <sysrqb> for reference: https://lists.torproject.org/pipermail/tor-project/2020-July/002937.html
18:08:08 <sysrqb> we haven't received many responses
18:08:44 <gaba> I wonder if we should design a survey and send it to everybody that we know is hosting onion services.
18:08:45 <sysrqb> Sebastian's mail has been the most informative
18:09:06 <gaba> To include your question but also to learn a little more on the setup that people use...
18:09:18 <GeKo> sysrqb: i was actually more interested about the setup of the onion services we know are affected of the issue
18:09:23 <GeKo> like nyt
18:09:30 <GeKo> and get in contact with those folks
18:09:42 <GeKo> but the mail to tor-project is good, too
18:10:07 <sysrqb> i think alec is the expert on those sites, and the nyt people do not fully understand the deployment
18:10:11 <gaba> GeKo: hiro and ggus wil have a meeting with nyt on thursday. We can tell them what we need to know
18:10:13 <GeKo> because i have some hope we can work with them to think about possible fixes
18:10:50 <GeKo> sysrqb: well, they should know their http requiremetns
18:11:03 <sysrqb> yes, that's true
18:11:04 <GeKo> and load balancer requirements and what not
18:11:13 <GeKo> while alec is doing the onion thing
18:11:30 * gaba reminds everybody that this meeting is being logged
18:11:33 <GeKo> gaba: yeah, it could be helpful asking them then
18:11:37 <gaba> ok
18:12:30 <gaba> so, what do we need or what are the steps to make a decision on rolling back that change or not?
18:13:22 <sysrqb> i've seen general support for how tor browser behaves now
18:13:32 <Jeremy_Rand_Talos> Am I correct in understanding that this kind of issue would be sidestepped if TLS over onion were the standard practice?  (Assuming that the UX issues there were ironed out, which I know is nontrivial.)
18:13:48 <GeKo> i think we should be prepared to roll all changes back that assume http://xxxxxx.onion is secure
18:13:56 <GeKo> if we roll that change back
18:13:57 <gaba> yrd
18:14:00 <gaba> yes
18:14:09 <GeKo> that includes onion-location, too
18:14:20 <sysrqb> onion-location is okay
18:14:23 <sysrqb> because that requires https
18:14:40 <GeKo> no
18:14:49 <GeKo> if we roll all things back
18:15:01 <Jeremy_Rand_Talos> gaba, was that "yes" aimed at me?  (Multiple people talking at once, hard to follow threading)
18:15:08 <GeKo> onions are no secure context anymore
18:15:34 <gaba> yes to what geko said about getting ready to roll back on those assumptions and also yes to what you are saying JEREMY_RAND_TALOS
18:15:34 <GeKo> that means password fields get warnings and such on http://xxxx.onion
18:15:38 <gaba> oops
18:15:40 <gaba> not in caps
18:15:45 <Jeremy_Rand_Talos> hehe
18:15:45 <GeKo> sysrqb: like the one on riseup
18:16:12 <GeKo> so we would not want to "upgrade" users, to, say the riseup pnion
18:16:14 <GeKo> *onion
18:16:30 <GeKo> to show them password field warnings because that's now insecure
18:16:40 <GeKo> while claiming onion-location enhances security
18:17:18 <GeKo> that rabbit-hole goes very deep
18:17:20 <sysrqb> i see your point
18:17:30 <antonela> is not onion location which enhaces security, in fact it doesnt have any security feature
18:17:43 <antonela> is the .onion what theoricaly upgrades your tls
18:17:49 <antonela> as discussed per months before
18:18:29 <sysrqb> but if ".onion are not always secure", then tor browser should assume ".onion is never secure"
18:18:36 <GeKo> yes
18:18:38 <sysrqb> because it doesn't know when it is secure and when it isn't
18:18:42 <gaba> yes
18:18:49 <sysrqb> sigh.
18:19:22 <Jeremy_Rand_Talos> Should I infer that the existence of these issues would increase the priority/desirability of improving the UX of TLS over onion (e.g. handling certificate validation sanely)?  Or are there other things that should be done instead?
18:19:50 <sysrqb> Jeremy_Rand_Talos: TLS over onion is one part of this
18:20:03 <antonela> so the fact that onions are protocol agnostic is not beneficial for us, finally we rely on certificates
18:20:15 <sysrqb> the other part of it is supporting additional adoption of onion services
18:20:22 <sysrqb> so they are deployed in a safe/secure way
18:20:37 <GeKo> antonela: you could see it that way
18:20:53 <GeKo> but i don't think we should do that
18:21:10 <GeKo> at the end of the day certificates don't buy you anything
18:21:38 <antonela> but at the same time is buying your onion security
18:21:43 <antonela> how it happened?
18:21:48 <GeKo> if the server-side admin continues to pass your traffic over http after the TLS got terminated at the edge
18:21:59 <antonela> yes, like regular services
18:22:26 <GeKo> we need to get onion site operators to understand that http://
18:22:41 <GeKo> does not mean to send traffic in the clear after the onion service
18:22:46 <GeKo> in the onion service context
18:22:56 <GeKo> which should not be hard
18:22:58 <antonela> right, we should have recomendations
18:23:08 <GeKo> (at least if sensitive data is involved)
18:23:15 <sysrqb> yes
18:23:16 <antonela> aka proper documentation on how to deploy a safe .onion
18:23:22 <GeKo> yes
18:23:24 <sysrqb> we should have better documentation about this, too
18:23:29 <sysrqb> si
18:23:30 <gaba> yes
18:23:32 <sysrqb> :)
18:23:37 <GeKo> that's not a thing we can fix at the browser level
18:23:42 <gaba> maybe the onion guides can include this
18:23:44 <GeKo> i'd argue at least
18:23:47 <gaba> the new project we have a small sponsor for
18:23:49 <sysrqb> gaba: yeah
18:24:08 <ahf> but documenting our ways out of this wont that just mean the argument becomes "we document us out of the semantics of http" ? i felt that was a bit a part of the discussion on the list?
18:24:12 <GeKo> like it is not an issue firefox can fix if folks mess up their setup server-side regarding tls
18:24:28 <Jeremy_Rand_Talos> So, is it feasible to make an onion service key sign an X.509 cert without running into cross-protocol vulnerabilities?  If so, it should be straightforward to validate TLS certs for onions without relying on public CA's
18:24:40 <sysrqb> ahf: no, there is advocacy needed as well
18:24:46 <ahf> i would think that would be OK, as there is only one TB and it's the reference tor browser, but i am sure that argument would arrive
18:24:49 <sysrqb> and making people understand that this is an expectation
18:24:53 <ahf> right
18:25:20 <sysrqb> Jeremy_Rand_Talos: not with v3
18:25:37 <sysrqb> while ed25519 tls certs are "allowed", no one supports them (as i understand it)
18:26:09 <Jeremy_Rand_Talos> sysrqb, that can be worked around to some extent I think.
18:26:09 <GeKo> so to get to the point about what to do
18:26:20 <GeKo> i think i am against backing the patch out
18:26:21 <sysrqb> right
18:26:31 <GeKo> and with it all the other things we worked on for the past years
18:26:55 <gaba> why geko?
18:26:56 <GeKo> i think that path down lies madness
18:27:55 <GeKo> gaba: why what?
18:28:14 <gaba> why are you against rolling back this changes
18:28:30 <GeKo> you mean onion-location?
18:28:45 <GeKo> or secure cookies?
18:28:47 <gaba> mm, i thought we were talking about the assumption of having the connection secure
18:29:40 <GeKo> yes, we are
18:29:59 <GeKo> the browser has fundamentally no way of knowing whether the operators of the server-side messes up
18:31:02 <GeKo> that goes both for normal tls setups
18:31:09 <sysrqb> okay, maybe we start the advocacy work on this as soon as possible
18:31:10 <GeKo> and for onion setups
18:31:19 <sysrqb> maybe we use #MoreOnionsPorfavor for this
18:31:23 <GeKo> the question is what we do about that
18:31:27 <sysrqb> and get people's attention
18:31:36 <GeKo> sysrqb: yep, that's a good idea
18:31:47 <acat> i agree with GeKo's view. what i'm not sure is how to find solutions for deployments where this can be problematic
18:32:05 <acat> in part because i'm not sure about the needs/problems with these deployments
18:32:07 <GeKo> for the issue at hand i can imagine hacking around that for the nyt and bbc
18:32:24 <GeKo> and plugging that problem for them until they fix their setup
18:32:38 <gaba> so I'm hearing that the decision you all want to make on this is : 1) not rollback any change and continue with the assumption on active connections with an onion service. 2) Work on documentation and reaching out to HS operators to help them understand how to better secure their systems.
18:33:05 <gaba> acat: I think for that we need to do some kind of survey and distribute it to learn how orgs and people are setting up their HS
18:33:22 <sysrqb> gaba: yes
18:33:34 <acat> but as GeKo said, i'd start with the ones we know have this issue
18:33:42 <sysrqb> i think that is the best path forward
18:33:52 <gaba> ok
18:33:54 <Jeremy_Rand_Talos> As a medium to long term goal, I do think we should consider (3) moving toward making TLS over onion less painful (though I fully understand that we cannot achieve that overnight and it's a nontrivial effort)
18:34:14 <sysrqb> Jeremy_Rand_Talos: we're considering SOOC for this reason - https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/text/draft-muffett-same-origin-onion-certificates.txt
18:34:15 <GeKo> Jeremy_Rand_Talos: yes, that, too
18:34:25 <sysrqb> but there are some other possibilities, too
18:34:32 <acat> yes, with that i guess we could always locally redirect all http .onions to https
18:34:58 <Jeremy_Rand_Talos> sysrqb, that's the proposal for basically doing unauthenticated TLS, right?  Or am I misremembering?
18:35:29 <sysrqb> Jeremy_Rand_Talos: it's self-signed, but not (strictly) unauthenticated
18:35:41 <sysrqb> okay. given we have a release next week
18:35:57 <sysrqb> and there is a conversation happening with a large onion service on thursday
18:36:21 <sysrqb> let's not rolback the changes now, and try working with them and understanding their setup
18:36:44 <gaba> once we understand a little more how they have the setup, we can come back to discuss again (1)
18:36:55 <sysrqb> we can always rebuild on thu/fri with all undoing all of our work, if their setup is completely broken
18:37:07 <gaba> ok
18:37:07 <sysrqb> yes
18:37:37 <Jeremy_Rand_Talos> sysrqb, well, self-signed is approximately unauthenticated unless you have some way deciding which public keys you allow, which AIUI is disabled by SOOC?  (Happy to defer this to after the meeting if you prefer)
18:37:49 <gaba> sysrqb: do you want to do a follow up on your thread to give a summary on this?
18:37:55 <GeKo> sysrqb: gaba: i don't think backing out the patch is dependent on what we learn
18:38:22 <GeKo> maybe fixing the problem for that particular onion services, yes
18:38:27 <antonela> are you really considering roll back?
18:38:41 <antonela> is like something over the table?
18:38:49 <GeKo> i?
18:38:52 <antonela> *rolling back
18:38:57 <GeKo> no, i am not considering it :)
18:39:04 <antonela> oh great
18:39:05 <GeKo> at least not seriously
18:39:10 <antonela> right
18:39:20 <antonela> im not sure what is serious and what is not at this point, so i ask
18:39:25 <acat> less patches to rebase :)
18:39:32 <sysrqb> tor browser is "the onion services browser", basically
18:39:32 <GeKo> lol
18:39:38 <gaba> assumptions are always tricky. We need to be very clear about them
18:39:42 <GeKo> acat: they are all upstreamed
18:39:51 <GeKo> so you would have _more work_
18:40:01 <GeKo> to get that all ripped out of firefox again
18:40:02 <sysrqb> if onion services are not secure, then tor browser is basically the same as 2015
18:40:07 <sysrqb> (now)
18:40:14 <GeKo> yes, exactly
18:40:25 <GeKo> (well, more or less)
18:40:29 <sysrqb> yeha
18:40:41 <acat> oh, but i thought we were talking about the security expectations too (in any case, joking of course)
18:41:10 <GeKo> yeah, there is some stuff that is still not upstreamed, fair enough :)
18:41:40 <sysrqb> my primary concern is making sure tor browser users are safe "now"
18:41:56 <sysrqb> i want that to include using onion services
18:42:10 <sysrqb> where onion services are "at least as secure as TLS"
18:42:24 <antonela> what about brave users upgrading their security visiting onions?
18:42:37 <GeKo> sysrqb: how do you make that _sure_ as a browser vendor in the tls case?
18:43:40 <sysrqb> GeKo: set expectations about how a TLS connection is used and the data sent over it
18:43:46 <sysrqb> and i think we can do the same for onion services
18:43:54 <GeKo> let's do it
18:43:54 <sysrqb> but that will take time
18:44:39 <sysrqb> "assume the onion service you want everyone to deploy"
18:45:00 <acat> maybe it's an opportunity to work more actively with these kind of enterprise deployments
18:45:02 <sysrqb> okay, we have some (more) work to do, if we're doing this
18:45:03 <gaba> yes, I think that is clear that the bug is on the HS here. And we need to set directives on how to secure their onion services
18:45:19 <sysrqb> acat: yep
18:45:20 <acat> maybe offer support?
18:45:26 <sysrqb> :) maybe
18:45:32 <GeKo> acat: yeah
18:46:14 <sysrqb> gaba: i guess we have our answer
18:46:19 <gaba> yes
18:46:21 <gaba> :)
18:46:23 <sysrqb> i'll follow up on the private email thread
18:46:24 <gaba> let's do it
18:46:32 <GeKo> sysrqb: good luck
18:46:42 <sysrqb> sigh.
18:47:07 <gaba> ok. anything else release related
18:47:08 <gaba> ?
18:47:21 <sysrqb> i don't have anything else
18:47:39 <GeKo> me neither
18:47:50 <gaba> sounds good. Let's close the meeting then
18:47:53 <gaba> #endmeeting