[HN Gopher] SSH3: SSHv2 using HTTP/3 and QUIC
___________________________________________________________________
SSH3: SSHv2 using HTTP/3 and QUIC
Author : kieto
Score : 272 points
Date : 2023-12-16 15:06 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| znpy wrote:
| Is this wayland all over again? We do three or four new things
| well, and everybody is supposed to just stop doing everything
| else ?
|
| Is this "a secure shell" (as in, somebody's personal spin on the
| topic) or like a new "official" direction?
|
| The readme isn't clear on these aspects.
| mseepgood wrote:
| It's obviously a personal project.
| uxp8u61q wrote:
| It's just someone's project. As far as I can tell it's
| unrelated to IETF, if that's what you mean by "official". In
| any case it's presumptuous for the author to call this "SSH3".
| brunoqc wrote:
| it's probably just ssh + http/3
| amluto wrote:
| What does "official" mean? The OpenSSH team? IETF?
|
| Anyway, SSH authentication is extremely inflexible, and the
| protocol is not particularly performant, especially on large
| bandwidth-delay links. Moving to HTTP3 seems like an excellent
| idea if it's implemented well.
|
| (Although... we really need a way to do TLS/QUIC to an endpoint
| without a domain name.)
| uxp8u61q wrote:
| The RFCs for SSH2 were all published by IETF, so I would
| definitely expect IETF to be involved in a project that
| claims to be "SSH3". If some random person started an OS
| project and called it "Windows 12", people would rightfully
| be confused.
| lnxg33k1 wrote:
| Agree I also think that we should leave naming stuff SSH to
| IETF and OpenSSH to OpenBSD, in this case the maintainer
| seems to be unrelated to both
| tlivolsi wrote:
| Agreed. The name is terribly misleading.
| ctz wrote:
| The IETF SSH working group was disbanded in 2006. You will
| be waiting a long time if you expect anything else to come
| from there by magic.
| aseipp wrote:
| Yeah, right now for auth, if you want to use e.g. OIDC I
| think the best you can do is to essentially shove everything
| in the square hole using very short-lived SSH certificates
| and OOB auth flow; e.g. "open this browser link to get a cert
| for the next 15 minutes/24 hours." So, you're basically
| treating short-lived certs like session tokens, more or less.
| I got this working with my own homegrown SSH CA
| infrastructure last year, but never took it out of prototype
| stage. Even slightly more flexible authentication would be
| very welcome.
| amluto wrote:
| Cloudflare offers this as a service. It's obviously a
| second class citizen (it's intensely buggy, has low
| availability, doesn't work especially well even on a good
| day, has incoherent configuration, and no support
| whatsoever).
|
| On the other hand, _all_ Cloudflare configuration seems
| incoherent, and it gets more so over time. I was recently
| highly entertained when I tried to access one of the Zero
| Trust [0] pages. The UI cheerfully informed me that only
| the new UI could configure Zero Trust, and it redirected me
| to a new domain that was IIRC "one.dash.cloudflare.com".
| You can't make this up -- maybe it's called One Trust
| internally? The new panel looked quite a lot like the old
| one except that the Zero Trust pages worked.
|
| Well, "worked". None of the Zero Trust config makes any
| sense.
|
| [0] Is there any logic at all to what lives under the Zero
| Trust umbrella?
| the8472 wrote:
| > (Although... we really need a way to do TLS/QUIC to an
| endpoint without a domain name.)
|
| Generate self-signed cert, let the client TOFU. And skip the
| HTTP part. Just like SSH. There's no reason to do things like
| a browser.
| amluto wrote:
| I think we could do much better than this with a small
| amount of creativity.
|
| But it really ought to be possible to securely configure
| locally-connected devices with a browser, and this is not
| really possible today.
| alphazard wrote:
| This is pretty neat, definitely better to move to UDP, so that we
| can have the proper response to unauthorized contact--no
| response.
|
| QUIC is fine as is though, no need to layer HTTP3 on top of it.
| heyoni wrote:
| Isn't it necessary for oauth?
| vlovich123 wrote:
| It might be easier to integrate but you've got a custom
| server and client in this case so it should be possible to do
| both without HTTP being involved for the server/client layer
| without an HTTP server? At least I think that's right but
| it's been a long long while since I wrote OAUTH code.
|
| Seems like it's primarily to implement the masking feature to
| pretend to be a normal HTTP server hosted on a port until the
| shared secret URL is knocked.
| the8472 wrote:
| The client and server need to talk http to the authorization
| server, that doesn't mean they need to talk http to each
| other.
| vlovich123 wrote:
| The reason they're using HTTP is to allow for hiding the SSH
| server so that it pretends to be a dummy HTTP server that
| responds to 404 on all requests unless you know the special
| random URL that hosts the SSH capabilities. It's a neat idea
| but overkill when you're not using that capability (didn't dig
| into the code so maybe it is bypassed if you don't ask for a
| secret URL). It does make me hesitant as I don't know how
| secure Go's HTTP stack is since an exploit there could expose
| quite a bit and I don't know that it's been hardened to host
| directly, but it is an interesting idea. May be worth hand-
| rolling a custom server to do the routing but at the same time
| it makes it easier to fingerprint. I think it makes more sense
| to separate the routing secret to a standard reverse proxy
| that's harder to fingerprint. One could imagine that the secret
| URL idea in a normal HTTP stack is susceptible to scanning
| techniques since there's only one route to guess.
| withinboredom wrote:
| It's likely the URL can be discovered via basic timing
| attacks as virtually zero routers do constant-time
| comparisons for route matching.
| codetrotter wrote:
| If the URL path is meant to be kept secret, such as here,
| they should use a password hashing algorithm such as for
| example bcrypt or scrypt for the URL path and hash the path
| of every incoming request and then check the hash of the
| path instead of the path itself
| jofla_net wrote:
| Yeah its overkill. Its like trying to hide a meth lab by just
| putting up a sign that says daycare. (and if you do a special
| knock on the door you go to the secret room) Edit: vs having
| an invisible building which if you knock on it the right way,
| materializes...
|
| The best thing about QUIC if its udp is definately that it
| could be made un portscannable.
| gnyman wrote:
| It's not exactly the same but you can "hide" a ssh server on
| port 443 with haproxy
|
| It's not really hidden as if you initiate a connection with
| ssh it will reveal itself, but if you try https it will reply
| as a webserver
|
| It world by looking at the first few bytes and deciding what
| to do based on that
|
| At one point I was running https/ssh/openvpn/custom-tcp all
| on one port..
|
| Here is someone else explaining how to do it, I don't think I
| ever wrote it up
|
| https://news.ycombinator.com/item?id=8925938
| stjohnswarts wrote:
| I never even thought of that, atlassian has a page on it:
| https://confluence.atlassian.com/bitbucketserver/setting-
| up-...
| neild wrote:
| HTTP/3 is almost indistinguishable from any other protocol
| running over QUIC, and QUIC itself is almost
| indistinguishable from random noise in UDP packets. If you
| want to masquerade as HTTP/3 traffic, just using UDP on port
| 443 will generally be sufficient.
|
| (Only "almost" indistinguishable, because it's possible to
| decrypt the first packets of the client's handshake and
| examine the ALPN parameters used to negotiate an application
| protocol. And QUIC may be further distinguishable from other
| UDP traffic through statistical analysis of packet sizes and
| response latencies, as well as the few unencrypted header
| bits.)
| egberts1 wrote:
| Not going there with anything HTTP/3.
|
| Disclaimer: I write network packet parsers for XNS/IPS/IDS for a
| living, to look for "bad things".
| qwertox wrote:
| I wish you would share some of your thoughts.
| mmaunder wrote:
| How intentionally vague.
| lajamerr wrote:
| I assume he means with the encrypted metadata in HTTP/3 /
| QUIC that it makes it harder as a security admin to "peek" at
| what is going on in the network.
|
| In my opinion its short sighted, because if we care about
| security, then we should care about user security and privacy
| as well. Because if the security admin has the ability to
| packet inspect stuff, so does a potential malicious app.
| insanitybit wrote:
| Odd, surely SSHv2 already suffers from inability to inspect
| on the wire.
| egberts1 wrote:
| From the Github:
|
| SSH3 is a complete revisit of the SSH protocol, mapping
| its semantics on top of the HTTP mechanisms. In a
| nutshell, SSH3 uses QUIC+TLS1.3 for secure channel
| establishment and the HTTP Authorization mechanisms for
| user authentication.
|
| So, it has nothing to do with SSH2; more about
| HTTP/3-QUIC security theater: hostname is still being
| sent over TLS/1.3 negotiation.
| insanitybit wrote:
| To be clear, my reading of the parent post is that the
| grandparent doesn't like HTTP/3-QUIC making it harder to
| read data off of the wire (ie: for internal security
| analytics).
|
| But I don't see how this is worse than SSHv2. In both
| cases retrieving the hostname / IP is obviously trivial
| since you just instrument DNS for the hostname and, of
| course, the IP is cleartext.
| egberts1 wrote:
| More like incomplete state machine for HTtP/3-QUIc
| NegativeK wrote:
| The owning organization or user should already have full
| admin on all endpoints.
|
| Malicious apps and attackers should not.
| nixgeek wrote:
| The standards bodies don't seem to buy the "bad things"
| argument and appear resolute on making it harder to MITM
| traffic on the wire and attempting to force IDS/IPS to all be
| run on the client.
|
| Is there a 5-10 year future where you just can't do this as a
| middlebox?
| jeroenhd wrote:
| Protocols supported MITM with correct configurations and it
| led to complete ossification of said protocols because
| middleboxes suck at following standards.
|
| It seems that at the time these features were dropped, most
| middleboxes have ignored features like exporting keys or
| configuring static RSA keys and went for CA-MitM attacks
| instead. You should expect these tools to break if they're
| actively trying to subvert protocols to do things they're not
| designed to support.
|
| I don't really see what changed, though. I guess static keys
| were dropped to provide forward secrecy, but other than that
| running your own rogue CA is as possible as it was 20 years
| ago. Middleboxes lagging behind in support for features like
| HTTP/3 is probably annoying, but that's because of a lack of
| implementation more than anything.
|
| You can still use your domain tools/MDM
| configuration/settings to configure an HTTPS proxy and
| firewall off the normal ports if you want to MitM your
| network reliably. If yiur prozy doesnt support http/3, it
| will happily downgrade your connection to HTTP/1.1 for you.
| Android's insistence on not actually applying user-installed
| certificates is a pain for many apps, but other operating
| systems will happily and silently drop security measures like
| certificate transparency when they encounter a user-operated
| MitM CA.
|
| The lack of MitMability comes down to Android being fussy,
| IoT devices you had no chance of ever controlling needing
| workarounds, and devices you don't have permissions to manage
| not being manageable. I really do wish Android would let MDM
| solutions inject certificates into the system store (though I
| can see why they don't with the wide range of stalkerware in
| the wild).
| egberts1 wrote:
| Second paragraph: "most middleboxes ..."
|
| It is the "others".
| password4321 wrote:
| My understanding is limited, but HTTP/3 boils down roughly to
| HTTP/2+QUIC.
|
| Major cloud providers are still shaking issues out of HTTP/2
| like "Rapid Reset" 2 months ago, the nesting and layers open
| gaps and new edge cases as naive implementations were clearly
| not yet battle hardened even against old attack families like
| amplification/resource exhaustion.
|
| https://news.ycombinator.com/item?id=37830987 _The novel HTTP
| /2 'Rapid Reset' DDoS attack_
|
| https://news.ycombinator.com/item?id=37837043 _HAProxy is not
| affected by the HTTP /2 Rapid Reset Attack_
| xorcist wrote:
| Not sure why this is downvoted. HTTP3/QUIC is a _lot_ more
| complex to implement than SSH.
|
| SSL is a very well studied standard, but it is clearly a
| committee product with lots of features built on enterprise
| standards like X.509, and SSH is made by a few protocol
| engineers with a razor sharp use case.
|
| It is easy to see why someone who audits parsers for a living
| would be much more comfortable with SSH as compared to a
| something over HTTP/SSL/QUIC.
| k__ wrote:
| How does it compare to Mosh?
| mcfedr wrote:
| Sounds like it as to solve completely different set of problems
| out_of_protocol wrote:
| If you want SSH via UDP, try mosh. If you have it installed on
| both client and server side, it just works, re-using auth,
| sessions etc fron ssh itself and only replacing sending actual
| session bytes back and forth. Don't break on unstable
| connections, have way lower latency
| georgyo wrote:
| Mosh and this project have fairly different goals.
|
| Mosh uses regular TCP SSHv2 to authenticate and setup the udp
| connection. As such your initial connection time is actually
| slower than just normal v2, and you cannot auth with something
| like oauth.
|
| Mosh is heavily focused on interactive sessions. You could not
| use mosh for batch programs easily.
| gabeio wrote:
| > Mosh is heavily focused on interactive sessions. You could
| not use mosh for batch programs easily.
|
| Correct, the goals are better human interaction with a high
| delay internet or server. Effectively allowing the client
| side to guess a bit as to where your input went (it does
| decently at it). But the key thing that I've loved is even if
| my client machine goes to sleep and I go to a different
| building I'm still connected to the server. That is
| wonderful. Agreed the connection time is slower. Mosh =
| Mobile shell.
| v3ss0n wrote:
| eternal is better than mosh https://eternalterminal.dev/
| binkHN wrote:
| Neat.
|
| > While mosh provides the same core functionality as ET, it
| does not support native scrolling nor tmux control mode (tmux
| -CC).
| ckwalsh wrote:
| Do you happen to know where I can read about how ET and Mosh
| each establish their connections?
|
| I have used Mosh for years and recently heard of ET, but when
| I tried it I experienced noticeable hangs that I don't get
| with Mosh, and I went back.
|
| I heard from several people that "ET is the new Mosh", but it
| won't be for me unless I can figure out/resolve those hangs
| password4321 wrote:
| I would probably choose between the two based mostly on their
| security track record, but I haven't needed the comparison
| yet.
| chungy wrote:
| "ET uses TCP"
|
| Right there, Eternal doesn't even try to cover the same use
| case as Mosh. It might be an alternative, same way regular
| SSH is an alternative, but there's no way it can be "better"
| mmaunder wrote:
| WARNING: This is not ssh3. This is someone's project. Install at
| your own risk.
| heyoni wrote:
| They should have called it SSHTTP3
| tsimionescu wrote:
| Secure SHell -Text Transfer Protocol 3?
| arp242 wrote:
| Anyone should treat any new crypto project which hasn't seen a
| lot of testing from others as such, no matter who it came from.
| Even if this was some sort of proposal of the OpenSSH people.
|
| The project is associated with the Louvain university; I would
| rate the risk of outright malicious tomfoolery to be quite low.
| tjoff wrote:
| Well, if it was a proposal of the OpenSSH people you'd bet it
| would get a lot of testing from others real quick.
|
| But to even consider calling it SSH3 is really quite silly,
| first impression doesn't exactly inspire confidence.
| arp242 wrote:
| "Confidence" in what? Ability to name things? It's making a
| mountain out of a molehill. It's certainly not an issue
| with the crypto or code.
| tjoff wrote:
| Judgement? Having attention for detail? Being in touch
| with the community?
|
| Just a bad look / first impression.
| password4321 wrote:
| If you want to tunnel UDP (WireGuard) or TCP (SSH) over the
| WebSocket protocol, check out https://github.com/erebe/wstunnel
| kernel_cat wrote:
| Also https://github.com/nnathan/monopiped. Just plugging my own
| project.
| PrimeMcFly wrote:
| Why would you tunnel WireGuard over SSH?
| tssva wrote:
| Perhaps reread the comment. It presents info for running
| Wireguard or SSH over websockets and not running Wireguard
| over ssh.
| password4321 wrote:
| Although not relevant to my post above, tunneling WireGuard
| over SSH sounds like an interesting challenge...
|
| Because WireGuard and SSH are at different layers of the
| network stack, it might be necessary (though slow) to bridge
| two WireGuard networks through a single TCP socket port-
| forwarded by SSH. I'm actually curious now what tools would
| best be used to accomplish this, how much effort would be
| needed to configure things, and how badly performance would
| suffer when faced with normal internet traffic congestion.
| oarsinsync wrote:
| > I'm actually curious now what tools would best be used to
| accomplish this
|
| "Tunnel UDP over SSH"
|
| https://superuser.com/questions/53103/udp-traffic-through-
| ss... has some suggestions
| IAmLiterallyAB wrote:
| Looks neat. Have you looked into using the new WebTransport
| protocol?
|
| https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ov...
| https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht...
|
| Still early stages, but it looks promising! Notably it supports
| multiple streams and unreliable datagrams since it goes over
| QUIC
| Jhsto wrote:
| Sounds like something to try in an internal network where you
| want to do X11 or Wayland application forwarding!
| zaik wrote:
| This is not related to OpenSSH or the RFCs for SSH3 published by
| IETF. It is just someone's random project.
| say_it_as_it_is wrote:
| 2 phd students
| stjohnswarts wrote:
| It still seems like a nice experiment if nothing else. If only
| it was done in rust ;)
| say_it_as_it_is wrote:
| Not if they wanted to complete the work in time
| nextaccountic wrote:
| I think it was a lot of hubris to call this ssh3, as if it were
| to be picked officially
| georgyo wrote:
| People are being perhaps a little too over dramatic here.
|
| Yes, this is not SSHv3 as defined by a standards body. It is very
| much SSHv2 over HTTP/3. (Which sorta sounds like how HTTP/3 is
| actually HTTP/2 over QUIC)
|
| But there is lots of SSH servers and clients, such as Dropbear
| SSH, OpenSSH, libssh, libssh2 (which is very different from
| libssh which also supports sshv2), and more. So I don't blame the
| creators from putting SSH in the name.
|
| The code itself looks like mostly glue code to other more well
| established libraries. I'm not saying that they didn't introduce
| new flaws, just that they did not roll their own crypto here.
|
| Their paper on their work is pretty interesting:
| https://arxiv.org/pdf/2312.08396.pdf
|
| I kinda hope this succeeds. The faster connection time is nice,
| but really OpenSSH is so change adverse that it's painful.
|
| IE, I have to have a pretty large patch sets to open SSH, one of
| them being HPN ssh for getting any kind of reasonable throughput
| over high latency links. This patch set is decades old and the
| problems well known, but OpenSSH maintainers do not care.
| Replacing the transport layer would force things like having
| reasonable window scaling.
|
| Another is loadbalancing and routing SSH connections. You cannot
| know where a client wants to connect to till after they done a
| full hand shake. This is pretty painful. If we had something like
| SNI we could route clients to the correct servers using only a
| single IP and port.
|
| I fully welcome these ideas and am glad a group is working on
| testing these concepts.
|
| Please don't dismiss things too hard too soon.
| dang wrote:
| Ok, I've put SSHv2 in the title to make that clearer. If
| there's a better way, we can change it again.
| nixgeek wrote:
| I don't think this is SSHv2 though the GitHub talks about
| reimplementation on HTTP semantics, and the paper illustrates
| SSHv2 vs SSH3 as being extremely different for session setup.
|
| In naming; Francois also explains SSH3 is a concatenation of
| SSH and HTTP/3 -- we can not like that here on HN (due
| seemingly to the lack of IETF involvement?) but it's what the
| project creators picked.
| gchamonlive wrote:
| Would SSHTTP3 have been more adequate for the project's
| name?
| magicalhippo wrote:
| SHT3 as in SSH over HTTP3
| dang wrote:
| Sure, but that project name is still in the title - what I
| change was the description. I don't know enough to say if
| the description needs to be more accurate. Others here
| surely do?
| wmf wrote:
| I think something like QSH (QUIC shell) might be a better name.
| adontz wrote:
| I believe security models for HTTP and SSH are pretty different.
| HTTP is usually public and anonymous, SSH is usually private and
| authenticated. While QUIC is definitely a great technology for
| HTTP use case, I'm not so sure about SSH. Not saying it's not,
| just it's something to reason about.
|
| For example x509 seems to be a disadvantage to me. I do not want
| anyone with a cheap DigiCert certificate be able to log in to my
| server, even as a result of some fat finger misconfiguration.
| OAuth assumes that both client and service provider can reach
| identity provider. Is it so for most serves? I am used to see
| pretty restricted setups, where many servers have no internet
| access and only update from a private package repository.
|
| From one side, I really like the idea of reusing HTTP. Who does
| new protocols these days? Everything is JSON or XML over HTTP.
| And it's good enough for most cases. But is it good enough for
| SSH? WinRM works over HTTP, but it uses Kerberos for
| authentication.
|
| Are there any significant real practical advantages? I don't see
| any. Are there any vulnerabilities, possibilities for
| misconfiguration, architectural flaws? Quite possible.
| nixgeek wrote:
| "cheap DigiCert certificate" is already possible with
| misconfiguration of SSH's TrustedUserCAKeys and without any out
| of tree patches. https://smallstep.com/blog/use-ssh-
| certificates/
| frutiger wrote:
| SSH Certs are not related to x509 PKI certs. SSH certs are
| created with ssh-keygen and is the result of one key signing
| another. The public portion of the signing key (ie. the
| "cert") needs to be distributed separately.
| vetinari wrote:
| Did you follow the link? The point was exactly setting up
| X.509 PKI for SSH authentication. Yes, it can be used with
| SSH, that was the GP's point.
| whatisyour wrote:
| you can disable X.509 for SSH
| frutiger wrote:
| I'm replying to parent not the overall post.
| vore wrote:
| I don't see anything about using an X.509 certificate for
| logging in, just for a client authenticating the remote server.
| And, even then, TLS has support for mutual authentication so
| someone with a cheap DigiCert certificate logging into your
| server is not really a problem if you could configure mTLS on
| the server side to accept only certificates in a certain chain.
| magicalhippo wrote:
| > OAuth assumes that both client and service provider can reach
| identity provider.
|
| You could use client credentials flow with a certificate. Then
| all you need is to register the public key with the server,
| much like good old SSH.
| HeckFeck wrote:
| > Who does new protocols these days?
|
| My business brain understands why, but my engineer's heart
| laments.
| iknowstuff wrote:
| QUIC is damn good though! Its minimal header has a very tiny
| overhead, and the protocol gives us so much for free. What's
| to lament? The userspace impl?
| sargun wrote:
| You can already use certificates to login via SSH. Usually you
| setup your own certificate authority and sign your own certs
| because they need special attributes.
| adontz wrote:
| SSH certificates (I encourage using them!) are not x509,
| absolutely incompatible.
| dilyevsky wrote:
| It's same general principle and same security model just
| different way of going about it. It supports CAs and
| extensions just like x509
| ikiris wrote:
| Aside from the weird claim of being SSH3, this project seems to
| not understand that ssh already supported cert auth.
| hackernudes wrote:
| Maybe similar to https://github.com/moul/quicssh
|
| I've done ssh over websocket before (to bypass a corp proxy)...
| been thinking about it a lot lately. I would love if mosh got
| support for different transports than just udp and it would be
| cool if the initial handshake could be done over http instead of
| ssh.
| password4321 wrote:
| SSH3 seems a bit of a clickbait project name, it's not clear to
| me that this project uses anything protocol-wise from SSH though
| it offers similar functionality.
|
| A PhD project from Belgium that combines several Golang libraries
| to offer HTTP-based authentication on top of backwards
| compatibility with OpenSSH keys, configuration, agents, etc. --
| it looks pretty solid but the associated paper titled "Towards
| SSH3" acknowledges "This article is a first step" in the
| conclusion.
| Ayesh wrote:
| SSH over QUIC would be nice.
|
| I don't see any advantage of layering HTTP/3 here. It adds more
| friction, and the only advantage it brings is being able to
| "hide" the SSH server over a URL path. I guess x.509 certificates
| would be fine, but SSH hostkeys, SSHFP or TOFU is enough and far
| more secure (because it implicitly pins the server public key).
|
| It's a relatively new project from the looks of it, so I'd
| definitely not use it anywhere half important having to create
| something interesting with QUIC and HTTP/3.
| mkesper wrote:
| Ssh hostkeys offer no solution for first connect to ephemeral
| hosts.
| jeroenhd wrote:
| If hosts are configured with SSH certificates as part or
| their setup, you can definitely skip TOFU and determine trust
| on the first connection. That won't work for the "I need to
| connect to a random IP address" scenario, but any cloud
| server exposing SSH can be configured with a certificate
| signed by a company/personal SSH certificate authority.
|
| You could configure something delightfully atrocious like
| https://github.com/mjg59/ssh_pki but I think for most use
| cases where you connect to loads of SSH servers, host keys
| and certificate authorities will work just fine. We can do
| with an ACME-like protocol for distributing these
| certificates, though.
| mcfedr wrote:
| Given how rare this is, using https seems like a great idea
| Ayesh wrote:
| Strict SSHFP can theoretically solve it [1], assuming it's
| used in the first place and has DNSSEC. I personally use it
| for all servers I manage purely because I like the additional
| security, but it not at all common and DNSSEC isn't all that
| perfect either.
|
| [1] https://aye.sh/blog/sshfp-verification
| cortesoft wrote:
| You can set up your ephemeral hosts to come up with properly
| signed host keys.
| ikiris wrote:
| SSh hosts have supported certs for at least a decade.
| acdha wrote:
| They list other advantages in the README such as tying into the
| web authentication model, which is pretty big for enterprise
| use as everything moves towards OIDC. If they could eventually
| use passkeys that'd be really nice.
| kdklol wrote:
| SSH supports passkeys:
| https://developers.yubico.com/SSH/#_fido2
| acdha wrote:
| With hardware tokens, yes, I use that. I was thinking that
| building it on a web server would be really handy with an
| integrated client you could use with iCloud, Windows Hello,
| etc.
| ikiris wrote:
| This already exists too
| ycombinatrix wrote:
| I already already use passkeys for ssh. libfido.
| ikiris wrote:
| You can already do all of this with ssh
| InvaderFizz wrote:
| It sure would be nice to be able to easily throw up a CDN like
| Cloudflare in front of my ssh server with no client side
| special sauce required.
|
| I didn't see it stated in the documentation, it this feels like
| something that might work for that setup.
| ryandvm wrote:
| Why are people obsessed with implanting CloudFlare right in
| the middle of everything they do? There is absolutely nobody
| that needs DDoS for their SSH server.
|
| I get that CloudFlare has been a well behaved netizen so far,
| but let's be real, it won't last forever. It never does.
| Eventually the shareholders start turning the screws and
| CloudFlare is going to succumb to the same pressures every
| company does and they're going to start extracting
| advertising value from their "customers".
|
| How about we save the CDNs for the serious stuff and just run
| our SSH servers and low traffic HTTP sites ourselves?
| JCharante wrote:
| Every personal blog is low traffic until it lands at the
| top of HN
| chrisandchris wrote:
| Which still means that the HTTP-server can be behind
| CloudFlare, but nobody accesses your blog through SSH
| (hence not necessary to put it behind CloudFlare).
| adastra22 wrote:
| Why would you intentionally MITM your SSH connection?
| InvaderFizz wrote:
| Absolutely nothing to do with DDoS in my case. I want
| censorship regimes to have to break large portions of the
| internet for their citizens to stop even the most simple
| leak vector. Let them block Cloudflare, Akamai, and
| Cloudfront.
| bitwize wrote:
| In the 90s it was commonplace to design a new protocol on top
| of TCP/IP. These days, all the tooling and infrastructure is
| for HTTP. Designing a new protocol, you'd be starting from
| scratch; HTTP is much, much easier to build an application on
| top of.
| unilynx wrote:
| I doubt QUIC is easier than TCP to build on. But it's much
| easier to get your new protocol through firewalls and other
| middleware when using port 443 than trying to introduce a new
| port (or worse: a new protocol number)
| jsiepkes wrote:
| Missed chance not to call it SSHTTP3 ;-)
| tenebrisalietum wrote:
| I'm going to use this to do UUCP over QUIC.
| wackget wrote:
| What if you already run a web server which uses port 443? Strange
| that the readme doesn't mention that scenario because it's
| extremely common.
|
| Presumably you'd choose a different port but then it'd be pretty
| obvious you're running something if your server has a random
| HTTPS server exposed on port 444 or whatever.
| xgbi wrote:
| Can't you simply `proxy_pass` the traffic with any load
| balancer or reverse proxy (that you probably have anyways if
| you use TLS)?
| okasaki wrote:
| You can run different hosts on one web server, like company.com
| goes to localhost:5555 (your app or whatever) and
| ssh.company.com goes to localhost:8443 (let's say you're
| running ssh3 on that port)
| qingcharles wrote:
| * depending on your web server/reverse proxy configuration
|
| [for instance, I run Kestrel and it really isn't designed to
| target more than one site; I do it, but it's like bending
| that Lego brick to make it fit where it shouldn't go]
| okasaki wrote:
| Yes I suppose, although you can always put a web server
| that does support it (like nginx) in front of your web
| server that doesn't support it.
| qingcharles wrote:
| Yeah, this is what MS used to recommend, although they
| now say their own version YARP is better.
| xyst wrote:
| Front load service with nginx server or load balancer...
|
| nginx exposed on 443:
|
| if route is /web then route to web service on port 1234
|
| if route is /ssh3-secret-string -> route to ssh3 server service
| on port 1265
|
| if route doesn't exist then 404
|
| ...
| extraduder_ire wrote:
| Can nginx proxy-pass encrypted data now? I tried this before
| and failed pretty hard, had to use HAproxy at the time and
| pass based on the hostname in the SNI header. Was still
| pretty unreliable.
|
| If so, I assume the encryption on the SSH is handled
| separately from the http headers.
| xyst wrote:
| https://nginx.org/en/docs/quic.html
|
| Since 1.25.0
| ajross wrote:
| SSHv2 is likewise trivially probable though ("nc $HOST 22"
| replies with "SSH-2.0-whatever"!), and that never hurt it. If
| you want to hide your services from attackers, there are many
| tools for that. I don't see why it needs to be part of the
| application protocol.
| epaulson wrote:
| I know this isn't an actual v3 of the SSH protocol, but if there
| ever is a version 3 of SSH, it really needs some kind of
| (encrypted) SNI or at least a standardized metadata block that
| can be passed to any jumphost without having the know the
| specifics of the ProxyCommand on that middlebox.
| idorosen wrote:
| `ProxyJump` already exists, so you don't need to know where
| netcat resides on the jumphost anymore.
|
| SNI-like metadata might have some adverse security
| implications, but a fancier ProxyJump with session routing
| would be nice.
| jhatemyjob wrote:
| So let me get this straight, from reading the README, the only
| tangible benefit is faster session establishment? With the
| downsides being, he's using a more complicated protocol, which
| apparently has slower throughput?? I guess this is a cool
| experiment but why would anyone use this over OpenSSH or libssh2?
| rubyfan wrote:
| Something about calling this SSH3 feels like when Comcast named a
| thing 10G.
| r1ch wrote:
| I feel like they're missing some benchmarks here, show off the
| benefit that QUIC brings! OpenSSH's fixed window size
| significantly bottlenecks throughput on long fat links. I'd love
| to see ssh+rsync running at 2+ gbps.
| pulpfictional wrote:
| There is also: https://www.psc.edu/hpn-ssh-home/
|
| > HPN-SSH is a series of modifications to OpenSSH, the
| predominant implementation of the ssh protocol. It was
| originally developed to address performance issues when using
| ssh on high speed long distance networks (also known as Long
| Fat Networks: LFNs). By taking advantage of automatically
| optimized receive buffers HPN-SSH could improve performance
| dramatically on these paths. Later advances include; disabling
| encryption after authentication to transport non-sensitive bulk
| data, modifying the AES-CTR cipher to use multiple CPU cores,
| more detailed connection logging, and peak throughput values in
| the scp progress bar. More information can be found on HPN-SSH
| page on the PSC website.
| formerly_proven wrote:
| SSH started out with a maximum window size of 128K, which was
| bumped to 2M in the mid-2000s. It'd be entirely reasonable to
| bump this to the 64M to 128M range; it's not a fixed buffer
| allocated for each channel, and the peers explicitly manage
| the window size, so there really shouldn't be any
| compatibility issues. This would already solve most of these
| issues, the more complicated parts of HPN-SSH aren't really
| needed, and things like multithreaded crypto are entirely
| unnecessary with modern CPUs unless you need to saturate a
| 100G link with one connection.
| nubinetwork wrote:
| > unless you need to saturate a 100G link with one
| connection
|
| Maybe not 100gig, but I routinely transfer data over 10gig
| links. I used to be a heavy user of HPN, but Gentoo pretty
| much stopped supporting it because the multithreading is
| supposedly broken.
| ironhaven wrote:
| Why is there http/3 in the middle? SSH over QUIC makes a lot of
| sense and was something I thought about before.
|
| The SSH protocol is designed to multiplex many "channels" over an
| encrypted tcp socket. Over each channel you can run things like a
| shell or SFTP.
|
| It would need some engineering but you could keep the same SSH
| features but replace the multiplexing channels over tcp with QUIC
| channels over udp. Where does HTTP/3 fit in besides to add
| overhead?
| egberts1 wrote:
| Do you want to maintain a state machine for each QUIC-SSH
| session 1-N pairing? Or worse, M-N pairing?
| CoolGuySteve wrote:
| Yes. The attack surface would be much smaller.
| wmf wrote:
| You can use HTTP for authentication.
| wslh wrote:
| Is there a security audit for this code?
| cvalka wrote:
| Why no support for mTLS? Certificate based authentication for
| clients is a must.
| anthk wrote:
| Meh. OpenBSD does it fine. If not, Mosh works great on flakey
| connections.
| jedisct1 wrote:
| This is cool, but calling that SSH3 is not appropriate. It's an
| independent project, not a new version of the SSH protocol. Sure,
| it's "SSH3" and not "SSHv3". Still, introducing a confusion with
| something that could be an official protocol is not nice.
| Sleaker wrote:
| What makes this any better than say, MOSH?
| JCharante wrote:
| Oauth for ssh sounds annoying
| zelly wrote:
| Seems cool but mosh already exists
| egberts1 wrote:
| SSH3 does not equate to SSHv2 over HTTP/3-QUIC.
| throwawaaarrgh wrote:
| Throwaway's maxim: no new protocol works without HTTP
| skywhopper wrote:
| This is a really cool project and a great idea that seems to be
| decently implemented.
|
| Calling it "SSH3", however, is misleading at best, and
| misrepresents what the project is. Please consider choosing a
| better name.
| gsu2 wrote:
| This seems bad?
|
| - SSH3 is a bad name: this isn't a successor to SSHv2 and will
| only cause confusion
|
| - The authors don't seem to understand that SSHv2 predates all of
| their chosen technologies, and provides "robust and time-tested
| mechanisms" they claim to be adding
|
| - How is "hiding your server behind a secret link" a feature?
| This is, at best, security through obscurity, which can be
| layered on any network protocol (e.g.
| https://en.wikipedia.org/wiki/Port_knocking); this implies that
| the authors don't have much of a security background...?
|
| - ...Which explains why they think something as complicated as
| OpenID Connect is a good thing to add to SSH (i.e.
| https://security.stackexchange.com/questions/148292/why-is-o...)
|
| - The abstract in the linked paper seems to conflate SSHv1 and
| SSHv2; I couldn't really bring myself to read much past that
|
| In summary: this seems bad.
| janosdebugs wrote:
| I concur. They seem to have reinvented a part of the protocol
| without actually addressing many of the issues of SSH. The
| paper also doesn't bother to go into details on any the
| advancements that have been made to SSH since the original RFC,
| such as keyboard-interactive, GSSAPI, etc.
|
| > Some SSH implementations such as OpenSSH or Tectia support
| other ways to authenticate users. Among them is the
| certificate-based user authentication: only users in possession
| of a certificate signed by a trusted certificate authority (CA)
| can gain access to the remote server [12]. Available for more
| than 10 years, this authentication method requires setting up a
| CA and distributing the certificates to new users and is still
| not commonly used nowadays.
|
| Somebody had an agenda to make SSH look as bad as possible. You
| can implement OIDC authentication with keyboard-interactive, no
| need for HTTP/3 for that. However, it gets very tricky if you
| want automated / script access, so it doesn't solve the
| authentication problem.
|
| As an aside, Tatu Ylonen, the original author of the SSH
| protocol, published a paper in 2019 titled "SSH Key Management
| Challenges and Requirements"[1], which is an interesting read.
| It would seem the authors of this paper should have at least
| read it.
|
| [1] https://www.ylonen.org/papers/ssh-key-challenges.pdf
| badrabbit wrote:
| Your points are great but SSH is extensible so openid connect
| support doesn't mean much since you can do it with existing
| ssh.
|
| "Security by obscurity" is only a thing if you're relying on
| that mechanism for security. People already configure SSH port
| knocking as you noted. It can be considered attack surface
| reduction and is a good feature given they're not using a
| secret link for any security control.
|
| One benefit of their approach might be how you can use TLS pki
| now instead if setting up ssh-ca's. Potentially you would need
| to manage less pki.
|
| But a criticism I have is how http* has much more vulns and new
| attack techniques being developed all the time unlike ssh. I
| can imagine LFI or request smuggling on the same http/2 web
| server causing RCE via their protocol.
| insanitybit wrote:
| > This is, at best, security through obscurity, which can be
| layered on any network protocol (e.g.
| https://en.wikipedia.org/wiki/Port_knocking); this implies that
| the authors don't have much of a security background...?
|
| This isn't security through obscurity. The url would be a
| _secret_. This is a form of capability security, where to
| connect to the server you must be able to name the server.
|
| A URL with a secret is, in my opinion, far more sane than port
| knocking, and will be much more efficient as well.
|
| > (i.e.
| https://security.stackexchange.com/questions/148292/why-
| is-o...)
|
| Your link doesn't support your statement at all. No one there
| answers "here's why oid is less secure", they say the opposite.
| commandersaki wrote:
| SSH over HTTP/(url) is a killer feature if you're working on
| hostile networks that block SSH and go even as far as to try
| and detect the protocol over the wire.
| idlephysicist wrote:
| I'd agree with you. The readme calls out "Significantly faster
| session establishment" and goes into greater detail later on.
|
| > Establishing a new session with SSHv2 can take 5 to 7 network
| round-trip times, which can easily be noticed by the user. SSH3
| only needs 3 round-trip times. The keystroke latency in a
| running session is unchanged.
|
| I, for one, can say that sometimes session establishment can
| take a little while but not to the extent that it would be a
| selling point (so to speak) for me to adopt SSH3.
| apatheticonion wrote:
| Interesting. Having HTTP/3 layered over the top, which I presume
| allows for SSL certificates to be applied to the connection,
| might result in the SSH connection appearing to observers as
| standard - uninteresting - website traffic.
|
| Assuming one could connect to an SSH server this way and tunnel
| ports, could this allow for a means to bypass China's GFW?
|
| China's firewall allows http and https connections through
| however VPNs, SSH and similar are detected upon connection and
| blocked on demand.
|
| Hiding a VPN connection by tunneling to a remote SSH server over
| HTTP/3, forwarding the VPN port and connecting to it might fly
| under the radar as it could be perceived as regular web traffic.
|
| Would be an interesting thing to try.
___________________________________________________________________
(page generated 2023-12-16 23:00 UTC)