2ton_jeff

Much nicer, thanks!

Thanks for that, and a tip of my hat to the HN community. Love this place.

Having written the aforementioned, I thought maybe y'all would be interested in a very very lightweight version of same done w/ my assembler of choice (only because it reminds me of Turbo Assembler from way back in the day).

  format ELF64 executable
  _start:
  	mov	eax, 1		; syscall # = write
  	mov	edi, 1		; man 2 write arg1 == our fd, stdout
  	mov	esi, .msg	; "" arg2 == const void *buf
  	mov	edx, .msglen	; "" arg3 == size_t count
  	syscall
  	mov	eax, 60		; syscall # = exit
  	xor	edi, edi	; man 2 exit arg1 == status
  	syscall
  .msg:
  	db	'Greetings, HackerNews!',10
  .msglen = $ - .msg

I don't think it gets much clearer or simpler than that, and more so that "man 2 xxx" provides all of the information you need for syscall goods anyway, it really isn't that bad :-)

if you compile this with fasm (http://www.flatassembler.net/) it produces a 174 byte ELF64 (and if we wanted to have some fun, we could lower that number by quite a bit still).

Cheers!

Edit: leading spaces for code

Late Sunday night here, but before I sign off for the night, thought you'd be amused to know that the name rwasa really, truly was an acronym from "Rapid Web Application Server in Assembler". I have historically sucked at coming up with decent names, and at the time pre-release this seemed like as good a name as any :-) I assure you any relation to Russians, African politicians, etc is wholly coincidence.

I am aware of Intel's patch re: psubusw usage, and interestingly chose the same solution when hand-compiling it as theirs well before I saw their patch to it (in fill window, which does make a substantial difference).

Have you compared my code to [your?] repo yet? I will endeavour to do so, though I am not sure submitting a fasm-based patch to that repo would make sense. Cheers

Admittedly I haven't checked recently, but before I released 2 Ton Digital I did a few test github projects and they all looked horrific so yeah I left it out on purpose. It's been on my "someday when I am bored" list since then (to fix up linguist so it all looks half-decent), and also why all the "library as HTML" on 2ton.com.au is self-highlighted.

> It's my understanding that random padding doesn't in fact make the attacker's job "much more" difficult. Only a little more, or not at all?

The BREACH attack verbage at http://breachattack.com spells it out fairly clearly, by adding random bytes to all of the HTTP responses, it makes small compressed HTTP payloads impossible to determine whether guessed bytes were correct or not (well, depending of course on the size variable of the random bytes added).

> Could you comment on how integrated the TLS stack is with the webserver?

The TLS layer is entirely separate from the webserver layer. I built the epoll, TLS, SSH, webserver and client as "IO layers", such that they can be stacked together arbitrarily (imagine epoll/IPv4 listener -> TLS -> SSH -> TLS -> Webserver, perfectly doable, albeit a little nutty).

Hey thanks! Contrary to popular belief, x86_64 assembler isn't really that bad to deal with. An eagle-eye perspective is simply that regardless of how good optimising compilers get, they can never really know my intent. My zlib implementation for example is consistently 25% faster than the reference version, despite me simply "hand compiling" it straight from the C source. There are lots of contributing factors that all add up to the end result as seen in the benchmarks.

The short answer is: there is no single reason, it is the culmination of all of the underlying bits of the library that made it what it is.

I added code profiling to rwasa so that you can run load tests against it and watch call graphs and individual function timings, which makes for interesting inspection of the library itself for specific "tricks" that were employed. (the library's page contains rwasa-specific profiling examples: https://2ton.com.au/HeavyThing/ )

Agreed regarding general trust in any crypto stack. I've been doing commercial software development for 28 years now, and my company's products all reflect this. Whether I expect high-value security sites to use my software in production or not, well I certainly do not. Hardened stacks are few and far between, and OpenSSL can by no measure be deemed hardened (though certainly getting better of late thanks to all of the bug releases). Do I expect that my entire stack is 100% bug-free? No, but one of the niceties IMO of doing assembly language programming is that it is far less error tolerant in the ways you describe. Reading all of the nasties re: security-related code, and then applying the commonly-accepted mitigation strategies was applied throughout.

Re: how do people contribute, it is on my list of things to do for github's linguist x86_64 support (which is why I didn't put it all on github to begin with).

At the end of the day, trust is a function of time and perceived scrutiny of the stacks at hand. We are getting there slowly but surely :-) Cheers!

Do you have specific criticisms of my work and/or attention to detail re: the TLS specification, and/or my library's application of modular arithmetic et al?

h2o is cool too, I contributed to that project early this year for their OpenSSL/DHE parameter settings.

Re: How much time, hard to say from my perspective since a fair amount of rwasa's functionality resides in the library itself. Start to finish for all of the showcase pieces and the library (from 0 lines of code to release) took 13 months of my life :-)

Author here: Feature request noted, although the one-logfile-per-day for me doesn't seem too unwieldy. I have not seen webserver logs stored in the way you describe, is that a common practice (each month's worth in its own separate directory?)

WYSIWYG sadly, hnwatch grabs the ID list to fetch from the SSE direct from firebaseio (and thus the public API). It was working a treat (and accurately reproducing everything from HN web-proper) prior to my releasing this... IDK what the proper course of action is from here... :-/

I attempted to call the 1 (844) 843-3473 number on the firebaseio.com site, I suspect it may be before their waking hours though.. my hnwatch now is not behaving at all like it was earlier though, and the only difference is that I released it here :-/

wow really bad now, my program is mostly useless without firebaseio... should I ring them?

outside curios request related to this submission, I have always configured webservers to return "400 Bad Requests" on HTTP/1.1 requests that lack a Host: header.

Still, every interaction I have had with HN this year always results in lots of hosts getting said results, and while this one is going, the most offensive host: 207.226.141.203 (dns: 207-226-141-203.static.pccwglobal.net) .. 1800 requests and counting from that host... ??

You obviously didn't scrutinize my code :-)

Coming back around, my automated syntax highlighter for sources doesn't like HTML entities, and the source_as_html you reference is indeed broken, but only for the HTML/browser case. Tah for the positive attitude, most of my sources "as HTML" are syntax highlighted to be pleasantish. My terminals are all syntax-highlight-free (vim: syntax off) and greenscreen like the olden day monochrome monitors :) The primary reason all of my code isn't on github is only because their syntax highlighting doesn't cover fasm/x86_64 assembler. It is on my todolist for someday when I am bored :)

Nice to meet you, too.

Curious as to what your intention is by pointing out my investment in years of profit-free GPLv3 development, and that somehow that is tied to the BSD license of the compiler's creator.

Care to elaborate on a better method? I miss Turbo Assembler, which is in part what brought fasm into existence.

"Advertisement" for GPLv3 sources?

I am not ashamed to openly admit my company would love more contract work, consider what I have contributed for free the "world's most expensive curriculum vitae". I'm interested to hear what other open source decision makers have to say about this, but 2 Ton Digital as a Software resource has made me bupkiss.

More the point, when someone wants something that requires a higher-than-average level of skill, we get business. The community as a whole gets to benefit because I keep turning it loose with no strings attached. Isn't that the way it is supposed to work?

again FWIW, I am the co-founder of a proper Australian registered business, I appreciate your concern. In an isolated environment, run it with strace -o nasties.txt or something similar. I assure you personally that the only outbound connects this thing does is to your locally defined DNS and firebaseio per the HN API, and is not terribly unpleasant to any host CPU (near as I can tell anyway, and that was before I enabled the 150 item limit on the main page indices).

See prior comment about the intentional omission of "/list" functionality

I noticed that the API from firebaseio has been really lagging since I turned this loose, not sure what is up, the code for the retrievals is pure REST though, nothing hardcore or nonstandard.

FWIW, I intentionally didn't implement a "/list" feature for it, as it was originally designed to be an in-house sorta ephemeral chat thing... not many requests for a public "IRC-style" ssh chat server, if there is by all means adding the feature for a "/list" wouldn't take long

my main desktop is also Mac OS X, I run vmware fusion + linux hosts when necessary, but all of my server infrastructure is linux anyway :-) linux kernel makes assembler so much easier than OS X and of course all of my library is catered for server-side infrastructure.

Yeah I spent a very interesting day chatting to heaps of people, haha, wasn't even logged in until just then :) glad it is appreciated. I can't handle too many chats all-at-once, but am logged into it now :) Edit: meant to include the origin of my day's sshtalk fun: https://news.ycombinator.com/item?id=9716459

Admittedly I am no webguy, the webpage for it was very much an afterthought, was just happy to release it... I'll see if I can get the boss to edit the content before my next deploy :)

Ha! Great question, one that I get asked semi-frequently. 1) Because unlike many, I can, 2) Because contrary to popular belief, it is not difficult. :)

ErrataSec hit it in one IMO:

http://blog.erratasec.com/2015/07/proxyham-conspiracy-is-non...

Weird, I meant to do my last post in reply to this, sorry it isn't inline correctly.

SSH2 specs are pretty clear about authentication methods. We (meaning me, the service provider) can accept or deny, negotiate any number of methods. With sshtalk, since all of the comms happen post-Perfect-Forward-Secrecy DH group exchange, I figure there is zero benefit for an anonymous chat service to remand any form of auth whatsoever, and sshtalk as I built it embodies that perfectly. It is not meant to authenticate YOU, it is meant to do the opposite of that, the only reason you know it is me you are talking to is because of domain inference and that I am @Sysop per the code itself. :-) all of these things I thought were good things.

Admittedly, I am no webguy, haha, my skills lie in old-school things... apologies if the web front doesn't do it justice