#tlsnotary-chat

dansmith_btc: yeah, dat guy got the idea from me

That moment when families look around and realize they have absolutely nothing to talk about... #facebookdown

if even morons like lizardsquad can do that, then let's face it, we're all screwed :)

waxwing, while running tests on aws, I occasionally get 10 PMS failed in a row during prepare_pms. The vars are shared.tlsver = 0301 and rs_choise=archive.org

ofs tls_11=1 in ini file

*ofc

this is worrying - why would the auditee ever use 0301 during prepare pms?

ws'ing shows that client hello has 0301

I guess there is some mismatch happening when auditee uses 0301 for prepare PMS but auditor uses 0302

dansmith_btc: yeah that could do it.

my suggestion to you: run a mega test with, like 500 entries until you see this behaviour

then both you and I can be sure that it's not just me here

i didn't consider that possibility - in that case, presumably, you would get pms trials failure

well running tests is one thing, but if you have tls_11=1 and you're seeing 0301 in the client hello, then something is wrong.

in TLSClientHello it uses tlsn_common.tlsver which may have been downgraded. We should use if int(shared.config.get("General","tls_11")): shared.set_tlsver('\x03\x02') there

oh - you mean from one audit to the next?

yes

is it possible?

i'll take a look but it sounds like a plausible source of a bug

but actually i remember that i tried to address that

by putting the reset at the start of the audit

ok, i c

and

i'm sure you already knew that, but just for reference

i don't know what's going on in that case.

you're saying this is happening very occasionally?

i could do a run of a large number as you say. is there any pattern in which sites?

waxwing, this is the branch I'm using https://github.com/themighty1/tlsnotary-1/commi...

I have wrapped some non-fatal error in try:except: - i dont think that is the source of this problem

also there are small fixes to websitelist

'retry audit on certain non-fatal exceptions' - could it be to do with this?

sometimes the test succeeds (with the default 30-ish entries), however with 500 this error will appear

does it happen when an audit is retried?

this happens during prepare_pms

when server responds with bad record mac

the server here is archive.org

ok but in that commit you edit prepare_pms

try/except block and continue.

ok i should stop and read it a bit more :)

yeah, it seems scary, but all I did is wrapped in try except, that's it

if only you couls see the diff ignoring the whitespace changes, that's be a very small diff

sure i get that it's a small change, but it is creating new execution paths

ok, I guess i'll undo that commit and try without it first

something i'm struggling to remember:

do we use 0302 for the prepare pms phase?

oh yes as i write it i remember

it's always supposed to be 0302 at that stage if tls_11 is true

i cannot understand how you can get 0301 in the prepare_pms client hello, if tls_11 is set to true. that should be impossible.

gonna take a little break. but before i do i'll pull your latest and start running as many sites as i can.

dansmith_btc: ^

waxwing, actually I just undid my retry... commit and rerunning the mega test

ok. i'll wait then?

u may want to wait until i confirm that it triggers again

oh hang on. maybe that's it. because shared.tlsver is a global.

and if you re-do prepare pms , then if it got downgraded, it would stay downgraded.

yeah.. i suppose it's true. hmm, my brain really doesn't work too well this morning.

yes, confirming the bug remains after undoing that commit

it's the same reason i had to shove that "reset from config" at the start of start_audit - if you don't reset, then you've still got the value from the last audit.

dansmith_btc: was there an earlier time when this *wasn't* happening? i noticed you doing tons of tests last couple of weeks. when did the problem start?

I remember running mega test way back, before the tls 11 thing

since then, i never had a successfull run

however I had successful test runs for the normal size websitelist, but not for the mega size

ok that matches my experience. i only ever used the default sized list.

i mean I had success recently only with normal size lists

yes, got it.

so what happens when the reliable site downgrades from 1.1 to 1.0? as far as i can tell, it should allow prepare_pms to return successfully on the second iteration. and from then on it should be tls 1.0 for the main audit (which i guess is a bug, but it should work).

i c where the bug comes from - we reset tlsver at start_audit however send_certificate gets triggered before start_audit

send_certificate is pre-preparing the pms before user presses start audit

process_certificate_queue . but yeah, that's clearly it. good catch.

best to just hardcode 0302 for prepare_pms purposes

i mean, it would be ok the first time (first audit).

yeah hardcode would be a fine bugfix, i expect.

no hang on.

if someone actually wants 1.0 audits and sets that in the config file, we need the prepare_pms to respect that.

yeah, that's a can of worms

the whole trouble started from .. this global variable in tlsn_common. it seems like we need it, but it causes a bit of a mess.

i got quite confused about it first time round, so i'm not surprised there's a bug left behind.

it's because we have to preserve state across different TLS session objects.

tlsn_session has to know what pms_session was doing, so to speak.

wouldnt the first step be to pass tlsver to auditor explicitely via p2p messaging? otherwise how will auditee communicate that he wants to use tls10

oh yes. did i forget that?

certainly remember thinking about it.

or maybe i didn't do it, and just figured 'oh people will have to use the defaults or otherwise tell their counterparty explicitly'

after all, they have to tell the counterparty other details, like the messaging channel and the pubkeys, and the reliable sites too

a load of stuff has to be synchronised; but if people just stick with defaults it's ok.

yes, there is no harm in not doing it initially, but right now when runnng test with random tlsver that must be communicated over p2p channel

otoh maybe it shouldn't be optional. just 1.1 and that's it.

with randomness, yes, i see.

bottom line is, youre right, a downgrade during the handshake should not in any way affect the operation of prepare_pms()

because prepare_pms is making the PMS which is unaffected by downgrades.

so yeah, hardcode it in prepare_pms to the value of shared.config.get()

if you want random variation in the tests, you can randomise the value in the config?

prepare_pms may run in paraller with start_audit because of the pre-preparing, relying on config will not do

passing tlsver to TLSNClientSession is the only option here

bbl

"prepare_pms may run in paraller with start_audit because of the pre-preparing, relying on config will not do" <-- i don't understand this.

if the tlsver used in prepare_pms is just what's in the config, that should be fine, whenver it runs.

unless the comment is connected with randomising (although i think it should still be fine like that?)

publicly available info needs no proof

maybe. private feeds?

i'm writing the history of TLSNotary as a blog post :)

actually i'm not. but somehow i ended up writing 3 paragraphs on 'background'

yeah, that story sounded incredulous to me

you mean the history of tlsnotary as a blog post is not believable?

no

why not? sounds fascinating :)

alumni-book style fascinating?

also suppose it's written, it should include paysty and stuff and so on

yes, that's what i meant.

3 paragraphs is of course not enough, more like 3 pages.

would you like to complete it? :)

waxwing: well, first you have to realize that I was absent until half-way

yeah, not sure. i don't focus too much on first 5/6 months. That was not so productive :)

second, until very recently, I didn't think of it as much more than a hack, then I saw Natanael giving it a theoretical perspective, so with enough theoretical spinning it's actually interesting academic stuff :)

which particular theoretical perspective do you mean?

waxwing: http://moderncrypto.org/mail-archive/messaging/... this, we can actually interpret is as some sort of a reverse-OTR authentication

i think we have seen lots of works on how you authenticate both parties in a communication, but without creating any proof that can be connected to both

but what if you want to prove something to a third party, but no one other than him?

i guess that is not a very hard problem

http://nsq.io/ interesting

waxwing: you meant the TLSnotary problem?

well, as long as nobody did it before...

oakpacific: well specifically imean that if you weren't constrained by TLS, you could construct such a system from scratch without too much effort

not saying it'd be easy to do it perfectly, of course

waxwing: but it always involves HMAC and so on

oakpacific: do you see any other use cases than (a) prove a transfer (b) prove a government ID or residence ?

it's a bit silly really isn't it, because any tlsnotary use case is a digital signature use case

unless, as you say, you deliberately don't want to prove it to anyone else but the auditor. then an attached signature is not good.

i wonder if blinding could play a role somewhere, like: you want to have the auditor read the plaintext to verify, but you want everyone else to be able to pass around a blinded proof and say 'the auditor verified this'. i can't see a use case though.

hmmm, maybe we can call it subliminal auditing and so on?

i guess all i'm describing there is a 2 stage: 1, auditor verifies, 2, auditor signs a message saying "I verify"

i start to wonder, have we broken the OTR deniability?

heh

OTR != TLS thankfully

but you would have to wonder if anything using a shared secret could be manipulated in this way

well, you could start with TLS 1.2 :)

waxwing: think about it, it's actually a trivial question

hearn is now telling me that he gets *all* his bank data digitally signed, and that he always has done..

btw i have to go in a minute

if one party gives up confidentiality, then you can just have the auditor creating everything

so if one of the parties is an informer

then your deniability is easily lost

waxwing: yeah, he said that quite a long time ago