log☇︎
512 entries in 0.724s
Framedragger: (ah. suresure. well if one plans to do that on millions of machines or more, better to use simple tcp sockets hm. say that masscan for 1st phase uses its own tcp stack to not exhaust kernel handles accidentally, etc...)
asciilifeform: nmap: 'Discovered open port 49152/tcp on 82.193.247.114' >>>>> https://archive.is/WAevR
Framedragger: mircea_popescu: (syn flood suspicion because sockets don't respond with anything, even when possible to establish tcp connection. and yes ping does seem to work.)
Framedragger: asciilifeform: seems that i can make it open 80/tcp, but it won't give me any data
asciilifeform: now it pings, but won't take a tcp socket.
Framedragger: (ideally, i would guess, it'd munch datagrams, too, because gossipd is to have no stateful connections of the tcp kind.)
Framedragger: aha, the way it'd work, it'd still scan only port 22 initially, because grabbing banners / doing stateful communication is much slower. doing the former is a matter of TCP SYN/ACK, with embedded 'cookies', no need for state
Framedragger: the whole "patch a DNS server and run alternative root" effort sounds interesting and useful, but, as you said, eventually the underlying layer would need to swapped for gossipd anyway. in gossipd, UDP/TCP as currently used by DNS may not even work. hence there may be a redundancy of effort;
asciilifeform: ( i could even see an argument that, e.g., rawtx eater doesn't belong in trb , and that tx ought to be injected via the ordinary tcp method. but i dun recall having this argument )
asciilifeform: Run Moar Tcp.
asciilifeform: USE MOAR TCP
asciilifeform: in other noose, https://archive.is/cgpZD >> 'This botnet with 145607 cameras/dvr (1-30Mbps per IP) is able to send >1.5Tbps DDoS. Type: tcp/ack, tcp/ack+psh, tcp/syn.'
asciilifeform: 'I know when ARPANET was being developed, they were interested in physical (wires-level) robustness (i.e., in case of war) – but I’m not aware of any scholarly research going on about how to protect TCP/IP from itself.'
asciilifeform: and it was plugged into a bank of tcp to serial (yes) converters, even.
asciilifeform: Framedragger: i won't touch a tcp 'gossipd'
Framedragger: imho one should not start prototyping gossipd on tcp due to the whole stateful nature of tcp. it would make things *appear* to be so much easier - implicit packet ordering and stream control, etc. - and when things eventually need changed it's gonna suck00r bigtime
asciilifeform: and that (b) means either being retarded (services built on tcp, such as www and irc) or some variation on udp.
mircea_popescu: as people (alf, mostly) pointed out in the intervening coupla years, there's absolutely no sane reason to marry gossipd to extant-internet, or tcp/ip or etc, as the original draft was trying to
mircea_popescu: but in any case the same tongue that licked tcp/ip also licked all of washington dc, not to mention etc.
Framedragger: tcp seq id's again? :/ right.
asciilifeform: (if all-comer can get a challenge, this not only makes you ddosable tcp-style, but turns your gossip net into a ddosatron weapon for any idiot who can get spoofed packets into it)
a111: Logged on 2016-08-26 13:34 asciilifeform: http://btcbase.org/log/2016-08-26#1529651 << ~tcp~ is evil, and i will kill it with my own hands. at least in the sense where i killed, e.g., git.
asciilifeform: tcp has no future, Framedragger .
asciilifeform: Framedragger: not only tcp, but the horse it rode in on. whole thing must burn.
Framedragger: [OT just for the record, it seems that rfc 7413 ("tcp fast open") won't do any good because (lo and behold) not only would it not save against syn floods, it'd actually introduce new attacks (2.2 and beyond). and existing mitigation techniques may not work. gotta love those people. yeah, fuck tcp.]
mircea_popescu: but all this stuff aside, back to the important point here : the "gossipd-like" thing contemplated for moving signed material (ie, v stuff) around is very much a different beast from the actual gossipd, which doesn't work on signed material ; presumably doesn't work on tcp etc.
Framedragger: is rfc7413 even supported by any tcp stack tho? (inb4 all tcp stacks must die!1 [not disagreeing in principle])
asciilifeform: Framedragger: tcp is evil.
asciilifeform: syn flood is challenge enough, because tcp is braindamaged.
trinque: you will not fix TCP/IP with teh botz
asciilifeform: the kind that accepts tcp conns from all-comers.
asciilifeform: trinque: 'nothing for showing up' is quite physically impossible with tcp.
asciilifeform: but they ought not to complain when 'my tcp connections are blackholing' or 'someone derived my rsa privkey using known-ciphertext attacks' etc.
phf: asciilifeform: going back to gossip conversation, my issue is that the gossip you talk about exists exclusively in your head, where's mp got a spec. there are aspects of gossip functionality that can be explored with current spec despite the underlying tcp transport. and like i said broken transport doesn't invalidate the application functionality. it will leak in practice through tcp shenanigans, but that's the nature of this
asciilifeform: as an only sane possible replacement for tcp.
phf: so then it's not even about gossip, it's about "lets have a replacement for tcp"
asciilifeform: phf: the handful of interesting aspects (single-packet friend-or-foe, no tcp) were outlined here.
asciilifeform: but it was ~always~ possible, from day1 of tcp, and this is evident to anyone with a copy of, e.g, richard stevens's 'tcp/ip illustrated'.
asciilifeform: it can also inject crapolade, into any tcp stream whatsoever. this is not a hypothetical, the actual mechanism that is actually used was recently discovered.
asciilifeform: usg can reset any and all tcp connections whenever it feels like it.
asciilifeform: tcp is evil, fundamentally because it violates the 'NEVER something-for-nothing-to-all-comers-FUCKOFFRANDOS' principle. ☟︎
asciilifeform: http://btcbase.org/log/2016-08-26#1529651 << ~tcp~ is evil, and i will kill it with my own hands. at least in the sense where i killed, e.g., git. ☝︎☟︎
phf: https://tools.ietf.org/html/rfc4880#page-13 (section 4.) over tcp. i have an incremental packet parser that you can attach to tcp stream and it'll give you packet-by-packet on the other end. that's probably not the right solution for going to war though
mircea_popescu: and while it would allow tcp/ip, it wouldn't be limited to tcp/ip
asciilifeform: the most galling thing is the VERY NOTION of a tcp that isn't porous. because tcp breaks BOTH of the two, as i found, iron rules of network sanity: 1) NOTHING TO RANDOS FOR FREE 2) NO OPERATIONS ON UNSIGNED INPUT
asciilifeform: ments, we show that the attack is fast and reliable. On average, it takes about 40 to 60 seconds to finish and the success rate is 88% to 97%. Finally, we propose changes to both the TCP specification and implementation to eliminate the root cause of the problem.'
asciilifeform: rther, if the connection is present, such an off-path attacker can also infer the TCP sequence numbers in use, from both sides of the connection; this in turn allows the attacker to cause connection termination and perform data injection attacks. We illustrate how the attack can be leveraged to disrupt or degrade the privacy guarantees of an anonymity network such as Tor, and perform web connection hijacking. Through extensive experi
asciilifeform: 'In this paper, we report a subtle yet serious side channel vulnerability (CVE-2016-5696) introduced in a recent TCP specification. The specification is faithfully implemented in Linux kernel version 3.6 (from 2012) and beyond, and affects a wide range of devices and hosts. In a nutshell, the vulnerability allows a blind off-path attacker to infer if any two arbitrary hosts on the Internet are communicating using a TCP connection. Fu
asciilifeform: lulzily, the iturd is the only phone that reliably works here in the house (because it supports telephony over tcp, transparently, instead of being stuck with tower, ~all of which are far away / weak)
asciilifeform: 'highland communications' << tcp-over-bagpipe ?
a111: Logged on 2016-07-06 00:14 shinohai: This is limitation of tcp/ip unfortunately.
asciilifeform: http://btcbase.org/log/2016-07-06#1497604 << of naked tcp, aha. ☝︎
shinohai: This is limitation of tcp/ip unfortunately. ☟︎
mircea_popescu: altogether the attempt to make a "web browser" work seems educational (read : selffuckstick) than anything. we don't even want tcp to survive, let alone html, css or js.
asciilifeform: (tcp, that massive barrel of liquishit, was designed before the discovery of luby code - or any of the subsequent 'fountain' algos)
asciilifeform: alert reader will realize that this abolishes tcp.
Framedragger: yeah i'm not certain how representative that figure is of whatever, honestly. with all metaphor removed, it literally is "the number of ipv4 hosts which respond to a TCP SYN to port 22 with TCP ACK [packet with ACK flag set]". i'm fairly confident that i haven't missed many hosts of this kind, but too should be replicated and tested.
Framedragger: uh need to check. but it's just a TCP SYN!
Framedragger: vc: just fyi, there appears to be a ~10k packets / second limit somewhere upstream, are you aware of anything of the kind? i'm just running some self-tests (using a program which has its own TCP stack, i.e. no use of kernel networking / sockets). same tests produce at least 10 times as much elsewhere. cpu not the bottleneck. just wondering what it could be
trinque: Please do not abuse the ws->tcp proxy. << what could go wrong
Framedragger: vc: re. https://box.cock.li/ - do you tolerate responsible and low-bandwidth netscans (TCP SYN and/or ssh-keyscan (which doesn't attempt any ssh auth)) perchance?
Framedragger: digital ocean e.g. - scanned more than querter of ipv4 space using TCP SYN (masscan) - so just to see which :22 hosts are up - received numerous abuse complaints from all over the net, all forwarded to me
Framedragger: (..in other news hosters seem to cave in to the "we gun ban your ip cause we saw three TCP SYN packets to :22 on our block" threats and do not allow any scanning whatsoever. online.net may be the exception and are cooperative, will see how they tolerate some scanz)
a111: Logged on 2016-05-23 02:23 Framedragger: asciilifeform et al.: a couple of representative ssh host key samples (e,N,ip_address) - two /8's - pipeline was masscan (sort of nmap+zmap with custom tcp stack) -> ssh-keyscan (manually parallelized) -> custom conversion into CSV
Framedragger: asciilifeform et al.: a couple of representative ssh host key samples (e,N,ip_address) - two /8's - pipeline was masscan (sort of nmap+zmap with custom tcp stack) -> ssh-keyscan (manually parallelized) -> custom conversion into CSV ☟︎
Framedragger: (scans are via simple TCP SYNs)
Framedragger: "With [... some custom] changes, ZMap can comprehensively scan for a single TCP port across the entire public IPv4 address space [on a 10Gbps pipe, looks like] in 4.5 minutes given adequate upstream bandwidth." https://www.usenix.org/system/files/conference/woot14/woot14-adrian.pdf - not bad
asciilifeform: and gossipd is considerably more general than a chat, it is to be a complete replacement for tcp/ip and packet switching as ordinarily understood.
asciilifeform: and incidentally what's packet size to do with irc, it runs on tcp.
asciilifeform: i routinely use, e.g., ida pro under 'wine' over x11 over tcp.
phf: tcp had non-blocking mode for a very long time
mircea_popescu: so he rewrites the tcp state machine in c, what :D
asciilifeform: mircea_popescu: aha, but then some bozo added tcp to it
asciilifeform: tcp over old slave banjo.
trinque: tcp 0 0 172.86.178.46:44113 185.30.166.37:7000 ESTABLISHED
asciilifeform: i did not include the tcp module for ts either
asciilifeform: PeterL: it is supposed to be a generic cipherator for tcp tunnel
assbot: Logged on 15-02-2016 18:37:44; jurov: and then it failed cuz must read /proc/net/tcp ?!
jurov: and then it failed cuz must read /proc/net/tcp ?! ☟︎
asciilifeform: i've experimented with tcp replay for testing
ascii_butugychag: but even then, a debugger that listens on tcp is a dangerous thing to have around
ascii_butugychag: the latter enciphers a plain tcp tunnel.
ascii_butugychag: phf: i have a patch for adding actual tcp to ts
ascii_butugychag: here's a riddle. why no straight tcp ddos against any of'em ?
asciilifeform: it can run in one of two modes, '-connect' where it services a fixed list of peers, AND NOBODY ELSE (no incoming tcp)
asciilifeform: incidentally a gossipd which conducts tcp pipes would at least threaten to begin to formalize the hierarchy.
jurov: http://log.bitcoin-assets.com/?date=07-01-2016#1362107 TCP socket that electrum wallet creates is easily replaced by serial connection, what stops you? ☝︎
phf: it sounds like ascii knows exactly what he's doing where's i'm struggling with simply getting all the required elements together. i've gotten as far as reliably reading gpg packets from a tcp stream, but i still have too many open questions. i'm thinking that my attempt is entirely pointless, but i'll continue it as a learning exercise. i publish code in a week or two, so that all can learn how not to write c :)
ascii_field: that tcp is retarded ?
ascii_field: whoever accepts tcp connections is ddosable.
assbot: Logged on 28-11-2015 20:42:43; phf: ben_vulpes: sure, so you're going to cap the size of ciphertext of what you expect to be nonce, which is fine, but after that you rely on state outside of gossipd (tcp packet from ip such and such) to drop all subsequent
ascii_field: http://log.bitcoin-assets.com/?date=28-11-2015#1333236 << if you use tcp or any other protocol where an enemy gets to hog so much as a byte of ram JUST FOR SHOWING UP, you're ddosable ☝︎
phf: ben_vulpes: sure, so you're going to cap the size of ciphertext of what you expect to be nonce, which is fine, but after that you rely on state outside of gossipd (tcp packet from ip such and such) to drop all subsequent ☟︎
ascii_field: i am deliberately not even mentioning gpu, because it is possible to have a useful computer with no vga board (e.g., you can speak x11 over tcp)
asciilifeform: anyway i'll be the last to cry for tcp.
asciilifeform: bitcoin as presently existing rides on top of tcp.
asciilifeform: the smallest known tcp stack is that swedish one
mircea_popescu: <asciilifeform> adding tcp would prolly double or triple the mass, though << the challenge would be to not write the worst piece of the completed assemblage.
asciilifeform: adding tcp would prolly double or triple the mass, though.
asciilifeform: http://log.bitcoin-assets.com/?date=04-11-2015#1315773 << have you (or anyone else) considered writing a simple tcp proxy for this ? ☝︎