The DMZ

« first day (1965 days earlier) ← previous day next day → last day (3213 days later) »

HamZa

08:02

All the commotion about the identity of Satoshi...
http://www.drcraigwright.net/jean-paul-sartre-signing-significance/
https://www.nikcub.com/posts/craig-wright-is-not-satoshi-nakamoto/

2 hours later…

Rory Alsop

09:42

@HamZa it's a bit crazy. Not sure I'd trust him though, given his history

HamZa

@RoryAlsop The second link provides several arguments that it's fake

Rory Alsop

@HamZa exactly

nothing absolutely conclusive, but definitely sounding like he's a scammer and not Satoshi

HamZa

indeed

AviD

@RoryAlsop oh apparently there WAS some conclusive evidence there, that he is NOT Satoshi

Rory Alsop

@AviD didn't see any in those docs that was definite (to someone like me who can't verify for myself)

AviD

09:48

yeah I didnt even look at it, just twitterbuzz

sorry I just dont think it is that important, one way or the other

even if he was satoshi

Rory Alsop

me neither, butr I'm sure it is of high importance to the blockchain community#

AviD

hehehehe

3 hours later…

AviD

12:50

so I'm looking at precisely defining SSRF (server side request forgery). Am I wrong in thinking that this is pretty much a more general case of RFI?

only difference I see is in context - SSRF might not execute the code server side, as RFI does. More on the nose, it looks like the direction is what is different: in RFI you are using an external server to attack the target, with SSRF you are using the target to attack some remote server (as if it is some sort of proxy).

Iszi

@AviD Sorry, you're losing me. AFAIK RFI = Radio Frequency Interference

AviD

remote file inclusion

Xander

13:48

@AviD I don't think so. It seems to me that the basic mechanics of the two are different.

AviD

thanks @Xander.

just had a long conv on this in the other room.

my conclusion: SSRF is a stupid name and not at all how any of this works.

but more to the point: the basic mechanics are the same, but the context is different, and the end result is very different.

Xander

@AviD Fair enough.

Matthew

Mods? security.stackexchange.com/a/122209/89876

AviD

@Xander still dont know why they decided to call that forging, when its simply proxying.

no credentials included

Matthew

Thanks @AviD :-)

etherealflux

14:01

@Matthew his previous question is even better

MickLH

You guys will be glad to hear I did the worst thing ever and rolled my own crypto.

etherealflux

rot26?

MickLH

Well I didn't specifically try to make it horrible on purpose, it's just nothing critical so I figured I'm allowed to have some fun

AviD

thats a gateway drug

etherealflux

rolling your own crypto -> injecting your own marijuanas

Xander

14:11

@AviD Yeah, I can imagine reasons why, but they don't make a great deal of sense.

etherealflux

@QPaysTaxes oh my god

it's like the sweet bro and hella jeff version of stackexchange

stage.artofcode.co.uk/questions/66

MickLH

@AviD It'll be fiiiiine. I just grabbed a canned crypto quality PRNG, and use that to pick a secret deterministic sequence of generating elements from a fixed group for modular exponentiation of each chunk of the message

etherealflux

set modulus to 1

unbreakable encryption + easily compressed output

MickLH

sadly I also need to recover the plaintext eventually

using only the ciphertext, and the secret

etherealflux

oh hush

you don't have to be perfect

50% is way more than 0%

MickLH

14:21

it's for a video game protocol, so in the case where something fails it's actually better to just throw away security and hope nobody is trying to ruin the game

etherealflux

What data are you encrypting?

MickLH

All of it, by default

etherealflux

between client/server or something?

MickLH

Yes, especially because clients are allowed to direct connect to each other

(over UDP)

etherealflux

Do the UDP packets still have cleartext frame numbers?

MickLH

14:26

I'd have to investigate because I don't remember what UDP is doing at the IP level

etherealflux

I don't think the spec includes one

if you don't have a cleartext counter, then you'll run into issues if (and when) packets are lost

MickLH

I just remember I was working with the assumption that attackers are able to send me arbitrary messages as if they came from my partner

etherealflux

hmm

MickLH

@etherealflux I have a "connection" concept and I use that combined with a maximum number of sequentially lost packets

etherealflux

asymmetric crypto would provide authentication; I think symmetric crypto would also work, as long as you can securely share a secret first

MickLH

14:29

Basically, each ACK response also contains an nonce for a challenge response

So the initial handshake creates a buffer of pending challenges, and each message is actually the response to a challenge

@etherealflux I'm using Diffie-Hellman to establish a shared secret

etherealflux

Could you use digital signatures instead? The overhead might get ridiculous if the packets are small, though

and I'm not sure how expensive that would be computationally

MickLH

That's the big issue right now, I'm afraid my message authentication is not sufficient

etherealflux

one issue is replay attacks

but I think your challenge system would avoid that?

digital signatures that factored in the frame number would also work

don't accept anything with a lower number than what you've already seen

MickLH

Right now I use the checksum and the shared secret to generate a hash for each message, so it's horribly vulnerable to malleable encryption because if you can fake the checksum you have a valid signature

etherealflux

malleable encryption?

can't quite remember thato ne

MickLH

14:35

And the challenge response should protect against replay attacks because once a message has been acknowledged, that same message would be rejected because it's encoded against an nonce that is not valid anymore

@etherealflux If the attacker can manipulate the ciphertext directly

The checksum is not a crypto quality hash, it's pretty trivial to just jank up a few bytes here and there to achieve an arbitrary checksum

I really should just use a full cryptographic hash function, but that leaves me with a hash bigger than most of my messages, which are already a bit bloated due to encryption

etherealflux

You could take only part of the hash, possibly

the question is, how tough does it need to be to break?

MickLH

Really I just need to coalesce all the messages from a short time period together into "super packets", and then I can sign that entire bundle at once

@etherealflux Well it doesn't really need to be secure at all, it's just a nice-to-have

etherealflux

a weird scheme might be to authenticate the contents of the last X packets with a single transmitted hash

but then packet loss would break everything

MickLH

I thought about that lol, I can even isolate "critical" messages so that most messages can have lazy authentication, because their effects can be easily reversed in a split second

I just am being lazy, really I should be coding right now but I seriously need a break

etherealflux

gotta run in a minute

academics

oooh, idea: make it for OSX only

no viruses :)

MickLH

14:44

lol I should pull some shit like that... "Encryption is disabled on OSX, because it can't get viruses right guys?"

2 hours later…

StackExchange

16:30

Stack Overflow: How We Do Deployment - 2016 Edition

Nick Craver on May 3, 2016

The third in a long series of posts on Stack Overflow’s architecture explaining how we deploy code.

Bob Ebert

17:11

Hi I was wondering how a hacker (lets say adrian lamo) would, from a local coffee shop, be able to open a reverse tcp connection back to him. Lets say he does not have access to the router and thus, can't change the the firewall rule/port forwarding to let the connection back to his computer

How would one do to bypass this?

Educational purpose

Because from what I know, the remote device/route wouldn't know to which device send the packets to. It would be dropped at the attacker's NAT's device (correct me if I'm wrong)

schroeder

17:37

Do you have evidence of this happening? It's like asking, "without an environmental suit, how does one breathe in space?" The point of "reverse" is that the remote target is the one doing the opening.

as for where to send the packets when the receiving device is moving, the simple answer is to set up a proxy or relay that does not move

Bob Ebert

Would it be possible to expand on your proxy solution? I am not sure in what direction to start searching

and, @schroeder I am not sure that they are able to make a reverse tcp connection without port forwarding either :p

schroeder

you set up a stable machine to proxy or relay incoming connections to your end target. As you move around, you update your IP with your proxy, and it routes the traffic between you and the remote target.

Bob Ebert

I understand, and I thank you for it, but I still have no idea on where to search for information about it. Forward traffic from proxy machine? how to setup a proxy machine?

schroeder

17:55

lookup SOCKS proxy, forwarders, etc.

« first day (1965 days earlier) ← previous day next day → last day (3213 days later) »

all rooms