On page 43, it shows very clearly, that women who do not have children have almost no earnings gap.
Society can "fix" this in two ways:
- introduce the same penalty for fathers, so that both earn less - which would IMHO lead to even less children
- lift up families/mothers and help women not experience this gap, by having full time high quality child Care, have laws that allow mothers to take their children to Work, etc etc.
Second one is much harder to accomplish, because it costs money and time and effort.
The first one is Just forcing fathers to stay at home while mothers go back to Work.
I don't think that's the right context to put this in. The correct context would be that families that have children face costs associated with having kids and the monetary portion of those costs seems to express themselves disproportionately as a decrease in the woman's earnings. Those costs probably represent a real decrease in the value of labor so "fixing it" might push us further from an optimal outcome, not closer.
Not sure I understand you correctly, but the study I linked shows that mother's earnings drop significantly after the First child. That has nothing to do with the significant monetary cost of children, which are added on top of that.
The alternative context that is probably correct is this is a cost of having kids because the kid makes the parent(s) less reliable/negatively impact a number of performance metrics and therefore make them less valuable. Families choose to make the wife the unreliable one and that is reflected in wages. "solving" that valuation pushes us further from an efficient market outcome making us all worse off. If the above is true, which I think it is, then the correct path is not compensating mothers for this cost, it's figuring out how to get families that can afford to bear said cost to have a lot more children.
It is more complicated than I let on and not as simple as class X is victimized. However, it's frustrating that this pushback happens only when a random internet comment is oversimplifying in the men have it worse direction and never when a massive institution is oversimplifying in the women have it worse direction.
As a father, I really can't understand how every article about this topic talks about as if fathers and mothers are just interchangeable. We are not.
Mothers carry their child for ~9 months, they give birth to that child. The bond between a mother and her freshly born child is bigger than that of the father.
Of course fathers are very important too, and yes fathers should spend more Time with their children in general.
But it's Just crazy to ask mothers to get back to work as soon as possible. Many mothers want to Work part Time, because they want to spend more time with their children. The issue is, that care work is not paid or valued nearly the same as work for money.
Also if you're feeding your young child like you are supposed to, the father simply can't feed the child, because we don't give milk.
Nearly all articles about this topic care only for how to get women back to Work instead of what's best for society and for families.
If that would be the Focus, we would talk way more about how to integrate children into the work Life and less on how to grow GDP.
It's not that hard to understand. The Overton window has been successfully manipulated by butt hurt commies at universities (that no longer call themselves commies, they call themselves * studies usually and converted from economic class to a fractured mix of dichotomies based on whatever they think they can exploit at the time). This means truly bonkers nonsense permeates university and society. At the same time we neutered the antitrust law won out of the last billionaire baron build up in the name of the free market (while ignoring that the natural outcome of the free market is monopoly and we need antitrust to break up market power abusers). So in that context we have insane people and billionaires (who also may be insane) pushing their own interests an the average to above average segment of society that just wants to have their 2-3 kids and be comfortable get steamrolled.
ruroco DOES prevent replay attacks, by saving the deadline (which is in ns) in a blocklist. It does not matter if the deadline has "passed", the deadline is added to the blocklist as soon as the packet reaches the server and is deemed "valid". So each packet is only valid exacly ONCE
I think what rmholt means is that ruroco does not improve security in the sense, that it has stronger and safer encryption/algorithms/... but that it merely "hides" existing services.
I would argue that it does improve security in the way that it reduces the attack surface of potential vulnerable services, because they are simply not accessible for adversaries.
On the other hand, having another tool running increases the attack surface, but imho that's very small.
Yup that's what I meant! And I am worried that a replay attack would be able to bypass ruroco. Thus ruruco is not a replacement for good SSH security, which you have to do anyway.
But like I wanna stress that I like ruroco and I might end up using it to decrease the internet noise on my home lab, but I'm just worried that someone might end up relying on ruroco instead of proper SSH security
a replay attack won't work, because every UDP packet data has deadline in nanoseconds.
Once this UDP packet reaches the server the deadline will be added to the blocklist.
If an attacker sends the same packet again, the server will check its blocklist for the deadline. It does not matter if the deadline has been reached or not. once the packet reaches the server, the deadline of that packet will be added to the blocklist.
Thanks for the feedback and pointing out ostiary. Fixing replay attacks is on my todo list, maybe I can learn some things from how ostiary does it.
Kind advice from my PoV:
Your comment could be read as "your project is shit, there is ostiary which has replay protection and yours doesn't".
I'm sure you didn't intend for you comment to not come across that way, and I also did not read it that way, but others could have.
Also keep in mind that ruroco is a very young project and is by no means finished. I was thinking about using one-time-pads or other encryption algorithms as well. I also posted this here to get feedback to improve my project.
So hopefully when I release version 1.0.0 all the issues that this project has atpit are resolved ;)
Ostiary prevents replay by salting. Client's reply is only valid for the unique salt that the server has generated and only for a short time and obviously only once.
A replay attack can only make the server do whatever the legit client intended it to do, just up to [timeout] seconds later.
the deadline that is sent from the client is being added to the blocklist after the command was executed, so sending the same packet again will not work, because the deadline (which is in nanoseconds) is already on the blocklist and therefore the command will not be executed again.
This effectively means that replaying a packet is not possible, because the server will deny it.
that is correct. The configuration is not even ufw specific, you could run any command that you like. This means you could also, for example, disable or enable certain nginx configurations.
"Maybe the OP simply hasn't yet heard about or used Wireguard."
I have, but I do not want to run a VPN solution on my private sever, for which I barely have any need. Also Wireguard, although VERY secure is still not "simple" software.
In addition there are usecases where Wireguard would not help, for example when I want to open up an http service for the current network that Im in.
You can definitely run an HTTP server behind WireGuard. WireGuard just adds a network interface that your server can listen on (e.g. your server would listen on a private address like 10.0.0.1).
OP's example was a great one. For example, let's say you visit your friends and you want to watch some content together that is accessible on your server. Using this approach you can open access to that without setting up Wireguard on friend's smart TV.
And Wireguard does use quite a bit of CPU if you are using a lot of network bandwidth. Small servers don't have that much compute power, so utilizing the port knocking somewhat removes that issue.
WireGuard has apps for most devices (macOS, iOS, Android, Windows). For smart TVs it's a bit of a mixed bag. Some of them do support VPN clients, and I know Tailscale works on the Apple TV now (Tailscale uses WireGuard under the hood).
If you're using the Ruroco client to proxy requests to the server, then you could do the same with WireGuard. You could have HAProxy (or something similar) proxy requests from your local network to the WireGuard interface.
No, the example is - you go to friends, join their Wifi, have the same external IP, send the knock from your phone/laptop to open 443 to that IP, and then you can connect from TV or their computers.
Port knocking only handles authentication (it's basically a crude password). It doesn't ensure the integrity (tamper prevention) or privacy of your connection. You would need to set up SSL certificates to handle that. You also need to get the TV to accept those certificates, which would require either a public DNS record (which exposes your server's IP via the certificate transparency log to any client that can issue a DNS request), or you would need to modify your friend's router's DNS resolver (which is even more complicated than installing a VPN, and assumes the TV uses the router's DNS server). A TV isn't going to have an /etc/hosts file that you can use to point a domain at your server's IP address.
So instead I would go to my friend's house, connect to their Wifi, and accept incoming connections from computers and TVs over the local area network and forward them through WireGuard. The TV would connect to my device via plain HTTP (which is fine since it's all happening locally), and then my device would be responsible for securely connecting to the server via WireGuard. This also has the benefit of implicitly revoking access as soon as I leave their house with my device.
TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. Certificate itself has nothing to do with DNS beyond the verification step.
And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).
And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.
You are both slightly wrong, and slightly misunderstanding what I'm saying.
> TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate.
TLS is mandatory if you want to ensure your connection isn't being eavesdropped on or tampered with.
> And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).
Yes this is called the ACME DNS challenge. I've used it many times, but if you want to be able to type in your server's domain name on a friend's TV and have it resolve to your server's IP address, then you'll need a public DNS record.
> Certificate itself has nothing to do with DNS beyond the verification step.
Yes it does, because most certificate authorities only sign certificates for fully qualified domain names, not IP addresses [1], so it obviously does involve the domain name system (you can view the domain name associated with a certificate in your browser, it'll be listed under the field "common name"). On a desktop computer you could get around this by editing the hosts file to map any domain name to any arbitrary IP address, but you can't do that on a TV.
> And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.
I never said anything about ports, I said a public DNS record exposes the server's IP address. The whole point of the domain name system is to convert domain names into IP addresses, so that you can actually use the internet protocol to connect to a server's IP (internet protocol) address. Try running dig from the command line on literally any domain name and watch it expose the server's IP. Malicious bots can watch the transparency log to find out about new certificates [2], then run dig or some other tool to issue a DNS request (to determine the IP address of the server), and then start hammering the server to search for vulnerabilities or even potentially to just DDOS it. If you use a wildcard certificate it's harder for attackers to figure out which subdomain to query to find your server's IP, but with WireGuard I don't need a domain name at all.
Yeah and I have a lock on my door. I still won't post my address on HN. It's all about defense in depth.
Another thing I forgot to mention is that port knocking only works if your hypothetical friend has a dedicated static IP. If your ISP decides to reassign your IP address then IP allowlists are useless. Many ISPs in the US run this racket where they make you pay for a "business account" to get a dedicated IP, even if you only want an IP6 address (which are plentiful).
My NUC easily pegs the network. I'm not sure you're right about this. Either way: you can just use WireGuard as a control channel, the same way this software does.
Wireguard doesn't require much, since it is part of Linux kernel.
But your use-case with http server is a good one. For similar cases I have used custom forward-auth service, but that still requires to have the web server accessible, while your solution hides it completely.
On page 43, it shows very clearly, that women who do not have children have almost no earnings gap.
Society can "fix" this in two ways: - introduce the same penalty for fathers, so that both earn less - which would IMHO lead to even less children - lift up families/mothers and help women not experience this gap, by having full time high quality child Care, have laws that allow mothers to take their children to Work, etc etc.
Second one is much harder to accomplish, because it costs money and time and effort.
The first one is Just forcing fathers to stay at home while mothers go back to Work.
reply