#bitsquare.io

oakpacific, to answer your question from yesterday

that's exactly (if i understood you correctly) what i spent so long working on about 3 weeks ago

auditee, in the tlsnotary js extension, fires a request to the server, has firefox check the cert validity, then cancels the request, then sends to the python backend the sha1 fingerprint.

then, when the auditee starts the tlsnotary ssl session (the real audit), when it gets the cert, it compares the sha1 of the cert it receives with the fingerprint it got from firefox.

if they match, all is well.

and as i said last night, the difference between this case and the reliable site/pms check, is that in this case, it's the auditee talking to himself, so a fingerprint check is enough.

waxwing: yeah, but both parties can agree in advance which site they are going to use

then they only compare the pubkeys they receive over the IRC

and if they are the same, they can proceed with the audit

oakpacific, that's ok as long as you trust you won't get hacked at the dns level, right.

waxwing: you can replicate the same behaviour in auditor no?

pls expand on that oakpacific

did you mean we should be able to do the same on the auditor as the long description i gave above for the auditee?

yes

that's what i was checking yesterday - you can't do that stuff without running privileged code, i.e. a browser extension

right, but i presumed it was because some difficulties in development

but it doesn't look like it is, is it?

as i was saying before, i didn't want the mess of having to create an extension on the auditor side.

waxwing: please be specific

you mean be specific about what i don't like about making an extension?

yes

it's a huge set of extra files, extra hassle for auditor, extra hassle for me to set up, all just to do one thing - validate a cert. seems totally disproportionate.

i feel like steps (1)-(6) i said yesterday is a more reasonable thing to do. in general terms it seems not to create any meaningful extra work for either side (actually, zero impact on auditee I think).

waxwing: but why can't the auditee and auditor install exactly the same set of files, with their roles being freely swappable?

they do, and they are.

oh sorry i see what you mean

the difference, as currently implemented is: when you run as auditor, you are just opening a tab in your existing browser. no extension is installed.

yeah, but you can just make two scripts, to start firefox in each mode

there's a bit of an involved process to get the auditee set up. we use a separate tlsnotary profile.

oh okay

yeah i knew that

i don't know, but can you estimate how long will it take you to implement step 1-6?

it was the most elegant, simple way to do it - this way the auditor can just run in his normal profile. I haven't actually tried running the auditor via a different browser. i think it might work like that, needs to be checked.

steps 1-6 was just me writing it out in detail. i don't think one approach is necessarily more complicated than another; what bothers me is that if we go the extension route for the auditor we have to screw around with the whole environment, adding a profile and an extension.

waxwing: what i meant is, i seem to completely unable to grasp the advantages of this approach you just listed, the only way that can make sense for me, seems to be for you to go ahead and implement it in a branch so I and someone else can try out and have a clue

*the step 1-6 approach*

maybe you can read through the code and try to trace what's going on in more detail.

that would actually be really useful in general. i hope it's not *quite* as hard to understand as it used to be.

waxwing: i *think* i understand what happens until now

but not the new approach

the advantages are: minimal change to current user experience, minimal changes to existing code generally (i guess especially on auditor side)

waxwing: i don't know, but it sounds like a lot of manual works for the auditor

as i said yesterday, it doesn't really change it at all.

it is already the case (in theory) that he checks the claimed domain against the claimed pubkey. now he has to do that a second time.

but in reality - this check was previously not implemented at all, so it was simply an omission.

(i mean, the omission was that we were not checking the pubkey of the 'reliable site' before)

waxwing: yes, but two manual checks, i would say that it's easy to miss a step and cause problems

the difference between 1 and 2 checks for *auditor*, who has to take his job seriously anyway. to me that is not very significant.

and they are done at the same stage, not at two different stages of the process.

but as i say, that's not a fair comparison anyway, because previously the second check was *omitted*.

waxwing: yes indeed, but from a pure UX perspective, it's still, in absolute terms, not ideal...

it would be more acceptable, if the program can fail somehow when the human misses a step

oakpacific, in other news i've just been given a dhl tracking number. i wonder if i can audit a dhl shipment (although of course there may be no practical value in such a thing, still interesting).

waxwing: there is value in it i believe

not for the chargeback-happy western customers obviously

hmm, they don't use ssl.

well, that's....errr i don't know how to say

with my cynic hat on, i'd say: why should they authenticate their tracking claims? would only help people sue them :)

of course, privacy... lol

with my black hat on, i wonder what could be pulled off with this crap. quite a lot.

the rule of thumb is you don't implement SSL when only privacy is at stake, it has to be a security problem :)

but still better than most of the Chinese sites

i have a account on a Chinese SNS

it has all kinds of mechanisms for protecting your account,security question, mobile phone binding, mobile phone OTP, and even intel IPT, but no SSL support at all....

www.mydhl.dhl.com is protected by ssl. seems not to be an EV cert.

oakpacific, what's SNS? Heard of it but can't remember.

social network service

facebook weibo etc

i wonder if these idiots are going to put my actual receiving address on this tracking info. i hope not.

ah "Electronic Proof of Delivery" uses ssl at least :)

oh lol, i put in my traffic number and apparently my delivery went to Villa Hermosa Mexico on 2 Sep 2013 :)

/traffic/tracking/

waxwing: yeah, but they can show you a tracking number, while proof of delivery would only be given selectively, after all how many are looking?

even if you gotcha them, they will say oh sorry it's a system mistake

(of course the reason proof of delivery didn't work for me is because it hasn't been delivered yet :) )

how crappy is it that anyone can view anyone else's proof of delivery?! now i know that some bod in mexico received something at a certain time, and can see his signature.

Marcos Cordova, if you're out there, I'm coming to get you :)

step 1 record every proof of delivery using tlsnotary

step 2 find those that you can use to sue DHL

step 3....?

step 4 profit!!

step 4 profit

lol

you can also get EPOD delivered to your email for more comfortable hacking.

hi there

hi

hi

but oakpacific you dont' need tlsnotary to record POD. It's out in the open for anyone to read. The page is delivered over ssl, but to get it you just need a tracking number.

poor old mr cordova in mexico, surrounded by the zeta cartel or whatever, and everyone knows he received a package at a certain time and date, and they even can see his signature on the receipt.

waxwing: in the fantastic world of Lex Cryptographia, a deliverer could totally destroy the POD after a certain period of time, so you have to record it :)

dansmith_btc, ping

waxwing, hey, how's life?

normalno :)

seeing any big troop movements? if you are, you could help out barry.

i'm in the middle of nowhere under a rock, so nothing happens here

more seriously, we've moved on in the discussion about certs. do you have a few mins to discuss it?

sure

dansmith_btc: if you have time maybe it's agood idea to update the OP of the forum thread to say we are looking for testers btw?

ok, so let's consider the question of the reliable site/prepare pms stage.

oakpacific, pls PM the text I'll update

if we don't assume we can trust our DNS, then both sides need to have browser (CA) verification of the pubkey they're going to use for that negotiation. agree?

waxwing, ok, I did scan your convo, i know what's the deal there. let me see if i have an opinion

dansmith_btc: i actually wrote something in the newest post on the thread, basically to test the compatibility of the banks we need volunteers, etc

dansmith_btc, yeah the convo has gone on and on ... might be better to crystallize it into a few points here.

oakpacific, updated the OP

dansmith_btc: tks

waxwing, my feeling is that we should hardcode the pubkeys into tlsnotary, because we must always assume that the auditor is an attacker who is sitting inside the wifi router.

yes, this was one option. but it seemed like the ugliest (if the easiest), because of course they're going to change fairly often.

there is even the question of whether different keys might be used in different regions for really big sites like twitter.

is there any safer solution though? i dont see any

the alternative is to use the pre-existing security model: each person trusts his browser to have a valid CA/cert database.

well, forget the region issue, even if that isn't nonsense, it's a separate issue to what's under discussion here.

right, the alternative is for the auditee to validate the rs's cert using FF. Then he can pass the cert/pubkey to the auditor. This will bee ao's job to validate the rs's pubkey by whatever means he sees fit.

dansmith_btc, yes, this was what i settled on yesterday. with the ao verifying manually at the end, just as he does currently for the main audit site.

but tbh just hardcoding pubkeys for now might be the easiest way, and give us some breathing room to find the most elegant solution.

right, because as you said ao must perform the audit carefully.

what about hardcoidng the IP? coz it seems easier to just make up pubkeys

btw one thing that cropped up yesterday: the 'domain' file is not strictly necessary to be sent from auditee to auditor, because auditor can instead (should) use the pubkey that he used in the audit, and for the domain he sees this anyway in the audit files.

or, i should check again in the code, whether the auditor is cross referencing that pubkey with the one he used. anyway, that's an obvious point, no discussion there.

oakpacific, big sites use all kinds of weird load balancing and whatnot for their "front end". i don't think thinking about IP is a good road to go down.

it's best to hard-code the whole certificate chain, not just the pubkeys, because the cert can expire and be taken offline.

and then there's no proof the the pubkey belonged to e.g google

dansmith_btc, i don't think that's a problem. i don't think an attacker can create a fake cert/pubkey where the pubkey is identical to a previously expired google pubkey.

ie there's no RSA 'preimage' attack, so to speak.

well not 'i don't think'. obviously just, not.

waxwing, I mean to vindicate us the developers, we should not include just the pubkeys, so ppl dont blaim us that the audit didnt go through because we supplied faulty pubkeys.

well, the audit won't go through if the cert has expired, right. it will stop at the prepare pms stage. then the auditor will debug and see that they need to be updated.

this is, of course, where the hardcoded part is ugly. it clearly isn't the *best* solution, but I don't think its failure will cause any catastrophes.

right, an the very next day google.com decides to change their cert. how will ao that it was not his fault

*will ao prove

if it fails it just craps out before the audit starts. auditor and auditee will just have to grab the up to date pubkeys and start again.

i mean, obviously, if this scenario were likely to happen often, then it would be a terrible idea. the assumption is it's extremely rare.

one thing - we must stop referring to google, google can't be used as it rotates certs.

well, it can, but it shouldn't be used.

well, the likelihood of 5 major websites changing their certs on the same day is slim of course

ok, just using the pubkeys would do then.

dansmith_btc, so let's say that's a short term fix, for the long term: do you see any way to automate that doesn't involve using an extension auditor side?

oakpacific, ah yes that could be part of the answer to my question. i remember playing with an NSS command lind tool for certs. but i didn't know what was going on.

waxwing, the long-term non-addon solution would be to parse FF installation's cert.db file from python.