#tlsnotary-chat

https://www.reddit.com/r/Bitcoin/comments/31ge8... :)

would read again

fascinating to see people send 05 02 00 02 to a server. wonder what possible exploit that could be.

and then immediately send 'GET taobao.com'

so i spent some time this morning thinking about the oracle concept. it seems to me that it would make a lot of sense to extend it to include "dark mode" signing.

that is to say, when the auditee gets a signature on the server response, send back the (tls stuff +) html and get the oracle to sign some subset of the html.

of course, that's more complicated, but the extra value it provides seems overwhelming considering that we already choose to trust the oracle with code execution and secret keeping.

the semantic problem of dark mode will never disappear, but you have the fallback of an auditor saying "that's not quite good enough proof for me, let's do a p2p session to prove it's real". The user/auditee can choose the level of personal data exposure.

of course, the more powerful you make it, the more you have to remember that ultimately there may be an Amazon employee that can read it (e.g. reading physical ram perhaps, but whatever)

it looks very good, but how does the oracle determine if it has enough data

oakpacific: well, i'm not proposing it as some wonderful thing :)

as for what the oracle signs, well, it would involve giving the oracle everything.

basically the oracle would run the existing tlsnotary-auditor script to verify the contents, then generate a new signature on the chosen subset of html.

btw not only amazon, but also github/archive.org . any smart server admin there could cheat by knowing the pms right. would be real time attack, but still.

oakpacific: the end of the road is kind of 'ditch tlsnotary, we just use this trusted oracle to store all secrets'.

waxwing: i propose that we can ask the auditee to generate a commitment or something like that for a page, which he can later extract a subset that convinces the oracle that it's indeed a subset of the original page, the oracle merely signs to confirm such a relationship, but say nothing about the validity of it, which will be up to the auditor to decide

"up to the auditor" -> yes that was basically my comment on the semantic problem, i agree on that.

waxwing: well yes, but the gist of the comment above, is to somehow proves the relationship, through what? block-by-block comparison?

oakpacific: the proof is in the earlier commitment of the server response.

notice that the oracle can run exactly the same script that an auditor currently runs to verify a .audit file.

then, it knows full html, and auditee can request a signature on a subset.

i was not proposing some magical crypto to prevent oracle knowing full html.

waxwing: surely not, just software-based obliviousness

what i am saying is, maybe the auditee can submit a subset with satisfactory quality to an auditor

how is this different from the dark mode problem?

and he can deduce from the data we provide that it indeed belows to a page that the oracle has looked at

i believe this is exactly the dark mode problem we discussed before.

oracle = auditor.

but the oracle cannot ask the auditee to submit something else

not sure what point you're making. do you agree that this is the same problem we're discussing?

waxwing: my scenario is: the oracle proves a subset of the page belows to a page that it has checked, then the auditor, upon being presented such a subset, can decide if it's of satisfactory quality, and ask for no more

it's interesting to consider that a very easy server implementation might lead to tons of servers all over the web, while a more difficult aws oracle one might be far more trusted, but fewer of them.

oakpacific: well, i claim that's my scenario :)

it's implicit (imo) that the oracle got the full html.

waxwing: yes, but why did you say "oracle=auditor"?

i meant that, if you wanted to implement dark mode for the oracle, it's the same cryptographic problem as trying to implement dark mode in a pure p2p tlsnotary auditee-auditor case.

waxwing: well, i can't recall bringing that up

ok, crossed wires i guess.

i was conscious of the fact that, if you propose this new addition, then it changes the level of trust in the oracle, since it sees the html.

it's the other problem:now you assume the oracle can have access to the full page, it can ask the auditee to create any kind of commitment that it chooses, that's much more freedom

and independent of the TLS protocol

you mean, i guess, independent of which *version* of TLS, not independent of TLS entirely, right?

entirely

well, without hooking into TLS, where's the trust in the html page?

because the auditor has access to the full page in plaintext

yes but where does he get it from?

TLS of coz, i meant we don't need to track to hack HMAC or CBC whatever to generate such a commitment

*try to

anyway, this is what i meant when i said: oakpacific: the end of the road is kind of 'ditch tlsnotary, we just use this trusted oracle to store all secrets'.

waxwing: i am not sure if i am clear: in the past we need to hack into HMAC and CBC stuff to implement the dark mode, because the assumption is that nobody other than the auditee can access the full plaintext, now if you assume the oracle can have such access as well, it can use some other crypto tricks to ensure that a certain subset definitely belows to a full page, for the convenience of a future auditor

oakpacific: yes, that's a good point, it can (it is different). Otoh why does it need to; it generates the full html itself, just like an auditor does, with the verify script.

then just if (provided.issubset(full)): sign(provided)

yeah, i suspect that if it's a crypto problem, but the oracle itself has to ensure there is some structural integrity

there is no crypto problem to solve once full html is known.

maybe we should set a minimum on the number of blocks

sure, maybe. but either way the fallback always has to be the auditor's (or recipient's) judgement as to whether the data is meaningful.

i actually envisaged a GUI for the application where you literally cross out the private data with a black line, just like you do on screenshots :)

i'm gonna try to update the server today using ThreadingMixIn to handle requests in separate threads.

don't want to "upgrade" to real webserver software, feels undesirable to add any dependencies.

that kind of "dark mode" thing can always be held back for version 2.0 :)

is the notary server going to be encrypted with TLS or just usual RSA?

btw i made some tests, it looks like trying to notarize most of the IM app's conv records is a dead end

wow, you should see my screen right now.

4 browser windows, 4 consoles, did 3 sessions simultaneously, seemed to be fine :)

waxwing: your screen? maybe you can take a screenshot with a proof that it's authentic ;)

oakpacific: depending on how we set this up, i expect we will need TLS auditee-server

oakpacific: :) good one

waxwing: if we keep on using RSA encryption then we could just include the pubkey in the sign bundle to prevent impersonation

yes, that's interesting. it has more of the p2p flavour, i.e. involving user key management. but one could imagine a use case, sure.

dansmith_btc: oakpacific OK, made push to both server and client code to support multiple concurrent requests.

tested with 3 concurrent, seems working. put a block on > 100 concurrent clients.

i'm sure it will get a bit slow with higher numbers, but that hardly seems a pressing matter :)

just nice to keep it ~100 lines of code for now with no external deps.

i put in a kind of half-assed ephemeral ID (6 random characters) that the client generates for each session.

hmmm....what if you have a bitcoin pubkey or something....then it's on the blockchain(voice starts to dim)

oakpacific: what were the things you tried that didn't work?

waxwing: whatsapp, wechat, web qq

oakpacific: ok. i thought we said there was no web interface?

oh no, that was snapchat wasn't it

right

but all of these are pretty js/ajax heavy

yeah i'm not at all surprised if they dont' work.

right.

like twitter. although i think an actual tweet can be audited.

sigh, these bastards, how am i supposed to use dillo with whatsapp from now on?

what should i try next?

oakpacific: git pull :)

actually, hold on for that

dansmith_btc: ping

it could have been pretty useful in censorship-circumvention. e.g., by taking a screenshot of a microblog that will be removed later, but pretty much all chinese sns sites don't use TLS on purpose

i'd like to update the vps server to the new version supporting concurrent requests

but you will need to put in 6 random characters at the start of each request, unique to each user dansmith_btc

i.e. /abcdefrcr_rsr.....:stuff

where abcdef is the id

oakpacific: yes that application had certainly crossed my mind!

what about weibo, or was that already covered. or is it already unfashionable.

i am now checking taobao's customer service system

waxwing: no tls

not strictly, they use it at the moment you are signed-in and redirect

didn't get it, they use it for sign in and then *switch back* to non-tls?

yeah, i am quite puzzled as well

waxwing: but no tls when you browse the site

that's for sure

they just want to hoover up all the data off the wire i guess.

without messing around with keys.

but put in tls to avoid the worst kinds of user account stealing.

pretty shocking however you look at it. they must own all the keys anyway.

okay, login-page is tls enabled, hmm, congrats on the progress

ironic really, they put tls on the only thing we don't want to audit :)

well, that's less malicious i guess, as full-TLS is no easy job from a IT perspective

gavin andreson and mike hearn will be in london on the 16th

i have a feeling someone else in this channel knows that :)

belcher: what is it, a conf?

seems like a talk type thing

that's not the best name out there for a meetup

coinscrum?

erhmm

theres only so many names you can invent of the form bit- or -coin-

and my blockchain sync is up to 2015

i was thinking earlier today, the chinese govt should really consider my idea of gitcoin - you mine a block by making a commit hash < target. then they wouldn't need baidu any more :)

well, git is centralized i think

no, but github is

sure, but gitcoin doesn't have to be ;)

oakpacific: 222.186.21.70 - - [05/Apr/2015 17:27:22] "CONNECT www.alipay.com:443 HTTP/1.1" 501 -

of interest? (i mean, alipay 443)

waxwing: Chinese IP address B-)

i still can't quite believe that something like taobao isn't secure

waxwing: hmmm, alipay is

taobao otoh

duh

right, that's why it got my attention. can you do alipay?

waxwing: yes sure

had it done with old tlsnotary many months ago

should be pretty easy

ok. that's something.

waxwing: but....

hey, this is what you got from the log?

oh, sorry

yeah, that's just someone sniffing for proxies.