00:02 <abliss> openssl s_client also says "verify error:num=24:invalid CA certificate"

00:04 <abliss> (btw, can you remind me why we have to MITM the ssl connection anyway? now that we're only powerbox-requesting the domain, not the path, isn't the CONNECT line itself enough?)

00:11 <isd> abliss: CONNECT wants a raw TCP connection, over which it expects to speak TCP to the end server.

00:11 <isd> We can't do that transparently, since the capabilities we're working with want to know more about http.

00:12 <abliss> ah, right, gotcha, thanks

00:12 <isd> So when we get a CONNECT we hand it a connection to ourslves, and then MITM the request it tries to make over that connection.

00:12 <isd> expects to speak HTTP

00:14 <abliss> it seems like the proxy server serves two certs, a self-signed one and then the regular target cert signed by the CA. It's the self-signed one that seems to have an invalid CA cert.

00:15 <abliss> (as well as also `verify error:num=26:unsupported certificate purpose`)

00:26 <abliss> i can't get openssl s_client to like the cert (nor to tell me anything more verbose than 'invalid CA certificate'.

00:26 <isd> It's entirely possible there's a bug in the logic that generates the CA, and it happens not to bother php

00:26 <abliss> I'm doing `echo -e 'GET / HTTP/1.0\r\n\r\n' | openssl s_client -connect example.com:443 -proxy localhost:4000 -verify 3 --verify_return_error -CAfile "$CA_CERT_PATH"` from inside the grain's network namespace

00:26 <abliss> is php one of those garbage languages (like python <2.9) that just skips all ssl validation by deafult?

00:27 <abliss> have you tried with curl? or any https client besides php?

00:28 <isd> It definitely didn't work before I changed the root certs in php.ini

00:29 <isd> But no, I have not tried it with any other clients.

00:30 <isd> Probably php is being more lax than other clients.

00:34 <isd> abliss: https://github.com/zenhack/powerbox-http-proxy/pull/3

00:39 <abliss1> thanks! not sure if i'll have left time to test tonight but i'll let you know.

01:09 <abliss> that patch didn't seem to make any difference :(

01:14 <abliss1> trying agin with `BasicConstraintsValid: true`, which i think may be necessary to include the isCA in the x509v3 fields

01:16 <abliss1> we may also need the Key Usage field: https://stackoverflow.com/a/5795827/1239095

01:17 <isd> Yeah, probably.

02:06 <abliss> ok, that seems to make it work.

02:38 <abliss> the problem now is the auth header.

02:39 <abliss> seems like the proxy is changing my auth header to something with a bearer token.

02:39 <isd> cool.

02:39 <isd> Wait, so you're trying to send an authorization header from inside the grain?

02:40 <abliss> yes

02:40 <isd> That won't work; the Authorization header is used by the bridge to determine which capability to use for the request.

02:40 <abliss> matrix server-server federation requires an auth header

02:40 <abliss> can we add another header that can smuggle it out?

02:42 <isd> abliss: look at headerWhitelist in web-session.capnp

02:42 <isd> Probably you want to use x-sandstorm-app-*

02:43 <isd> Did someone try to port phabricator? Noticed there's an entry there, but afaik we don't have an app for it.

02:44 <abliss> isd: but now i have to add another proxy on the way out to restore the header?

02:44 <isd> I guess so.

02:49 <abliss> so it's the same set of whitelisted headers for incoming http api requests and outgoing requests?

02:49 <isd> From what I can tell; it looks like the implementation is pulling from the same list.

02:51 <isd> shell/imports/server/drivers/external-ui-view.js if you're interested in opening up the hood

04:01 <abliss> i'm so sick of sandstorm stomping on my auth header... now i'd need another MITMing proxy for sandstorm itself to live inside, to restore the headers that it's stripping

05:53 <JacobWeisz[m]> Wooo, SandCal in the experimental market!

06:04 <isd> It feels good to get that out the door.

06:06 <isd> Reminder office hours tomorrow

17:28 <isd> Reminder: office hours in 30 min

17:35 <JacobWeisz[m]> Probably won't be there, friends are on their way.

18:02 <abliss1> jitsi phone bridge seems busted again

18:05 <isd> Just me so far. Is anyone else planning on joining?

18:06 <abliss1> trying

19:38 <isd> ill_logic: are you still having trouble getting oriented with meteor? I'm wondering if maybe doing some pair programming might get you over that hump?

20:43 <ill_logic> Ian Denhardt: I appreciate it. I think it may be a good idea.

20:43 <ill_logic> It's mostly a momentum thing.

20:44 <JacobWeisz[m]> Ian, you might wanna tell the mailing list SandCal is open for testing.

21:16 <isd> Yeah, I probably should.

21:39 <isd> I guess we need to figure out how to do pair programming remotely.

21:40 <abliss1> tried FlooBits?

21:51 <isd> I haven't

21:59 <isd> ill_logic: what editor(s) do you use?

21:59 <ill_logic> vim

21:59 <isd> me too. Maybe I can just proxy a tmux session somewhere.

22:03 <ill_logic> hah. I mean, could just ssh right?

22:03 <ill_logic> or I guess it would have to be on a server running a development sandstorm

22:04 <abliss1> vim should work in my ttyd spk....

22:04 <abliss1> (but you couldn't do much testing in the sandbox)

22:16 <isd> Yeah, getting a full dev setup running (including both of us being able to see the server via the browser) is a bit fiddlier than just ssh

23:59 <abliss1> Ian Denhardt: am I wrong to think that whatever golang I write for a TcpPort-sharing grain will have to be 100% rewritten in kj-dialect C++ when it gets integrated into sandstorm?

23:59 <isd> Right now the IpNetwork implementation is in javascript, actually