| 17:54 |
PeterL |
Where I work we just had a network update, we were told "be careful about your browsing, we now have the ability to see all your traffic. But nobody will be looking at it unless there is a problem." I wonder what pest traffic looks like to their monitoring software? |
| 17:59 |
asciilifeform |
PeterL: closest'd be traditional vpn, most likely |
| 18:01 |
asciilifeform |
PeterL: see also. |
| 18:03 |
* |
asciilifeform at one time wanted to specify 'packets can have random rng padding beyond 496 bytes -- but -- crucially - with no frag reassembly on receiver end, and only padded if peer aint answering the usual way' but already imho toomany movingparts |
| 18:04 |
asciilifeform |
^ notionally, it ought not to be possible to write an ids rule against pest that won't nail dns & similar |
| 18:04 |
asciilifeform |
atm can, cuz the 496b thing. |
| 18:05 |
asciilifeform |
afaik 'no frag reasm, wait for 1st frag & discard any others, use only 1st 496b' would req os support |
| 18:08 |
asciilifeform |
see also etc |
| 18:08 |
bitbot |
(trilema) 2018-09-18 asciilifeform: there's a 'max never-fragged', afaik 508 byte |
| 18:08 |
bitbot |
(asciilifeform) 2021-11-15 asciilifeform: (moar nuanced -- a pest packet's 496 oughta sometimes be elongated with random rubbish up to the 516 possible w/out fragging, and on receipt discard all bytes above 496 and process then normally) |
| 18:08 |
bitbot |
Logged on 2023-07-01 12:14:53 asciilifeform[5]: re: censors, was thinking : possibly pest oughta take 1st 496 bytes of incoming packet (i.e. permit rng padding to random size within some range), station ops may need to trade 'no frags' for 'not making pesticity obvious to snoops by size' |
| 18:12 |
PeterL |
wouldn't a traditional vpn have all the traffic going to one address, pest would look more like having n vpns where n is your number of nodes connected? |
| |
~ 2 hours 40 minutes ~ |
| 20:52 |
asciilifeform |
PeterL: was thinking from packet snooper pov, but yea |