You should use netcat or socat, since those are designed to allow you to fire text at a remote port and display the result. Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.
That is not exactly correct. If you use netcat newlines are not send in the correct way. The nc command will receive character number 10 from the terminal and write character number 10 on the socket. However text based protocols don't use character number 10 for newlines, they use character number 13 followed by character number 10.
That means if you use the nc command to connect to a server with just about any text based protocol, you will be sending malformed commands. However many servers will accept what you send anyway and simply do the exact same thing when they see a character number 10 as they would have done if they had seen character number 13 followed by character number 10.
OTOH using the telnet command to connect to a server with a text based protocol will do the right thing. The telnet command will send the proper 13 followed by 10 sequence when you press enter.
It is true that what telnet does in this case is nothing like the telnet protocol. As a matter of fact, the telnet protocol is not a text based protocol. The telnet client will recognize the difference because a real telnet server will send some binary data immediately when a connections is established.
So to talk a text based protocol using the telnet client is a better choice. If you are going to be using a binary protocol, nc is more suitable (but of course then stdin and stdout should of course not be a terminal). One problem that nc still has is that it doesn't properly handle half open connections correctly, not that I think telnet is any better, it is just that when pushing raw data over a TCP socket, nc is my usual choice, and in those cases half open connections matter.
Speaking of ssh tricks, I wrote this tool a few years back to allow the ssh client to choose from multiple alternative ways to connect to an ssh server.
However, the number of 2048-bit primes is so astronomically large (think ~10^600), that you're more likely to randomly guess the prime factors of a given key than you are to find a collision between any two RSA-4096 keys ever generated -- past, present, or future.
Actually that's not correct. Where you say more likely, you should instead have said slightly less likely. But that is assuming the key generation algorithm generated random primes. In reality the primes being generated are not truly random. And that flaw in how the keys are generated is the whole point of the article.
The second point of the article is that you don't need to fully understand the flaw in order to exploit it. They had a hunch and tried it out. Computing GCD between every pair of keys is the obvious approach, but I would have thought that would be infeasible due to the extremely large number of pairs to be considered. And they did in fact make some optimizations in order to speed up the computation. It does look like their algorithm is still quadratic time in the number of keys, but it may have smaller complexity with respect to the key size.
Managing to identify all the repeated primes is quite impressive.
Once you have identified that the problem is real, and which devices are affected, a determined attacker could try to identify all the primes that could be generated by that class of device. You actually just need the first of the two primes. As explained in the article the first prime tend to be less random, and knowing one of the two, you can compute the other.
Others will get the wrong end of the stick- even if you found the hoed through innocent means- assume that you hacked or were trying to hack into their system, and act accordingly.
And those companies are causing an unnecessary risk to all the reasonable companies. I think for the majority of people, the first reaction when finding a security hole is to find out how to contact the persons responsible for it in order to get it fixed. How many times will a person do that if the reaction is either being ignored or being threatened with a lawsuit? I don't think many people will keep being helpful if that gets them such threats, and I think most people will stop the first time when they get such a threat.
So some people will just start ignoring the security holes, and others will start thinking about other ways that knowledge could be used. Some of those may come up with various sorts of abuse as the other way it could be used. If reports about security holes were handled in a reasonable fashion by the majority of companies and never resulted in threats against the person who reported it, then there would have been an overwhelming chance that it would be found by an honest person and reported before it was found by somebody wishing to abuse it. But those unreasonable companies are keeping most of the honest people silent and turning the rest to think in a less honest way. They are increasing the risk to the entire industry.
I'm curious how the case would turn out in court if a security hole was found in a completely innocent way, and the person who found it decided to publish details on the security hole after the irresponsible company had tried to threaten that person to silence because they didn't want to spend resources on fixing their stuff.
Another method of protecting against physical theft of the HDD and passphrase guessing is to utilize online cloud-based services for key distribution.
I'll me propose an actual API that could be used for this. First of all the master key is encrypted with two layers of encryption. First it is encrypted using RSA, next it is encrypted again using the password. The RSA encryption step needs a bit of extra work to make the encryption indistinguishable from a sequence of random bits. By default an RSA encryption doesn't look exactly like random bits. The point is that the RSA encryption is from an interval [0;n[, where n is the product of two large primes. Since n is not a power of two, not all possible combinations of the bits will result in a value in that interval. But after performing an RSA encryption you can just add a random multiple of n to the value, and that essentially solves that part. Once you have made that minor step between encrypting using RSA and encrypting using password, it will be such that no matter which password you try, you cannot know if that password was correct until you have done the RSA decryption as well. The RSA secret key is on the server, the RSA public key is stored in clear on the encrypted disk.
Decryption happens using this protocol:
Key material is decrypted using the password, which was entered.
Client choose a random blinding value to hide the real secret from the server.
Client sends a request to the server for RSA decryption.
Client use the RSA public key to validate response from server. If invalid, it keeps trying until it receives correct decryption.
Once client has correct decryption it opens the encrypted filesystem.
Client finds an HMAC key inside the encrypted volume and computes an HMAC of the request it sent to the server.
Client sends HMAC to the server to prove that the request the server handled previously unlocked the filesystem.
The HMAC key is completely unrelated to the actual encryption key. The server knows the RSA secret key and the HMAC key. All the server will ever know was that a request was made and if the validity of the request was subsequently proven to be valid. The server learns nothing about the key material. As a matter of fact, a completely valid session of this protocol could be produced using only the key material on the server.
If MIT were to choose to turn, say, 18.128.x.x over to ARIN, they'd have to completely reconfigure their network
True. If they were to return any addresses at all, they can no longer announce a route to 18.0.0.0/8. (I don't know if they do announce it like that, but having a class A, they could). If they can no longer announce a/8 they would have to announce smaller blocks. If they were able to squeeze everything into half the addresses they have now, then they could announce a/9 and return the other/9. If that is not possible, then they would be forced to announce their addresses as multiple prefixes and thereby increase the global routing table size and cause problems for everybody else.
If you have a/8 and would want to return some, you shouldn't do so unless you really think it is feasible to squeeze all your usage into half the space you used to have. You also need to ensure that whatever address space you are left with is enough to last until everybody else have switch to dual stack (or IPv6 only). Since the purpose of returning addresses is to prolong the transition (which isn't much of a useful purpose), it also implies that the more addresses you return, the longer those you have left will have to last. That's not much of an incentive to return addresses.
Apart from BGP is it really much of a problem to return just small fragments of address space? Do you have to change your network, if you weren't using those addresses anyway? The answer to that question of course is yes. If you were to just change your BGP announcements to stop announcing some addresses that you weren't using anyway, nothing would break yet. However if you were to return them and they got reassigned, things would break, if you had only changed your BGP announcements.
The reason things would break is that the route to those addresses would still end up somewhere inside the same network, if it originated there. Taking your example, a packet from 18.127.1.2 to 18.128.2.3 would never leave the MIT network even if the destination address had been returned, because the routers inside the MIT network would still think it was a destination within their network. It would propagate through their network until a point where some router would report no route to host. So both the BGP announcements and the routing inside the network would have to be redone before addresses could be returned.
It would make more sense for them to set up a brand new IPv6 network, slowly migrate everything there, and once it's all done and if they don't need IPv4 anymore, they can then turn the entire 18.x.x.x back to ARIN.
Even once they have everything set up as dual stack, they would still want to keep IPv4 for as long as there was anybody else on IPv4 only who they wanted to communicate with. The point at which it makes sense to return the IPv4 addresses to ARIN is also the point at which nobody else would want them anymore. It is not like the demand for IPv4 addresses would drop to zero overnight, but it is probably going to be close to it.
Most likely we will eventually reach a point where nobody would bother to setup new IPv4 networks, and the demand for addresses will decrease. The decrease in demand will not be very visible since there won't be much of a supply either. But those who are already dual stack won't turn down their IPv4 support right away. Just as their isn't much to gain from turning up IPv4 when everybody else is dual stack, there won't be much to gain from turning down IPv4 support.
At a later date the work to keep administrating IPv4 in parallel with IPv6 will be more significant than the work it will take to remove the last few IPv4 dependencies. At that point people will turn down IPv4 and return the addresses. And nobody will care about the returned addresses.
It's true that the initial allocation of IPv4 address
if anybody tries accessing them from IPv4-only nodes, they should be redirected to ipv4.google.com, ipv4.facebook.com
That is not the way forward either. Such a redirect would work for all those people that don't need it, and it would fail for those people that do need it.
The main domain should be available over both IPv4 and IPv6. Each client use whatever it has. The problem with that is that some networks are misconfigured, and some software doesn't do fall back to another protocol very well.
ipv4.google.com already exists for those people who have a misconfigured connection. I think it was set up prior to IPv6 day last year, and it will probably stay around for many years to come. But a redirection like you suggest won't work for those people with a broken connection because you cannot send a redirect back to a client that is unable to contact the server in the first place. For the majority of users where things just work that redirect would work, but it wouldn't be desired. The goal is for the transition to happen with the majority of the users never noticing a difference. A period where all IPv4 only users get redirected to a different domain doesn't achieve that.
Had clients that defaults to IPv6 had good fallback to IPv4 to begin with, then we wouldn't have had the need for separate domains, redirects, DNS whitelists, IPv6 day, etc. We would have seen content available over IPv6 2-3 years earlier than we do now.
Nothing like having a really long download session abort because Windows spontaneously canged your IPv6 local address.
I don't use Windows, so I didn't know about that bug. But I would say Microsoft should go and fix that bug. And if Microsoft won't fix that bug, then you should consider using a different operating system, that doesn't suffer from said bug.
The correct implementation of privacy extension would by default do the following: At system boot each interface is assigned two link local addresses as well as two IPv6 addresses per router advertised on that network segment. One of the two addresses would be based on the MAC address and hence be static, the other address would be randomly generated (according to the spec). Incoming connections can use any of the IP addresses. Outgoing connections will use the randomly generated address (unless the application explicitly overrides that choice by binding to a different address). Every 24 hours more randomly generated addresses are added, again one link local address per interface plus one per router advertised on that network segment. The new randomly generated addresses are made default. The old randomly generated addresses remain on the interface until they are no longer in use, and only then they are removed.
If Windows didn't suffer from the bug you mentioned, then it would notice that there was an open TCP connection using that old address and thus would keep it on the interface even though it wasn't the default for new outgoing connections anymore.
And when I said that the above should be the default, it should of course allow the user to configure it. For example the 24 hour interval could be configurable. In addition there is a few possible tweaks. For example you might not need privacy extension on link local addresses. It will be of limited use since for a link local connection the other endpoint can see the MAC adress anyway. In addition the 24 hour interval could be made in a way that doesn't synchronize the adding of new addresses. If you have two interfaces and receive two prefixes on each of those there is no need to update all four addresses at the same time. Doing it at the same time might reveal some information to the peers you are communicating with, and it will also reveal information about your uptime. Instead the first assigned address is given a lifetime chosen uniformly between 1s and 24h. After that it is updated every 24h.
But what I got was this......the run rate is such that if we reclaim ALL IPv4 address space, including yours and mine that we're using right now, we still run out in 2019.
I tried to do similar calculations a little while back and came up with 2020 as the time we would run out. So I think your calculations are right, the one year difference just means a bit of uncertainty. Another way to interpret the result of this calculation is that by 2019 there will be more devices on IPv6 only than the total number of devices that will fit in IPv4.
Some DNS servers are completely broken and drop requests for an AAAA record. If your local caching DNS server is doing this then you basically end up seeing all web requests, etc. being slow since the browser will look up an AAAA record to find out if the website is accessible over v6 and the DNS server won't respond.
Some DNS servers are worse than that. They will not only fail to lookup the AAAA record, but in the process of attempting, they will put garbage into their cache and cause subsequent A lookups for the same domain to return an incorrect IP address.
If you bother to look at the consumption rate you'd realise that even if all of these addresses were returned to the pool they would buy a few weeks and then we'd be right back where we started.
They may have lasted two months if they were returned a year ago. But if they were returned today, they would be consumed as quickly as APNIC could file a request. Extrapolating the usage trend in the APNIC region from before the pool ran out suggests that they by now could file a request for 10/8 networks to meet actual demand.
We are well past the point where returning addresses will do any good. They will be consumed just as quickly as they are returned, and doing so will fragment allocations even more leading to an explosion in the routing table size.
Those who actually have unused addresses, which they could return have a few options:
They can return the addresses, which will allow somebody else to postpone the work they need to do by a couple of weeks, but does nothing to solve any problems.
They can try to figure out when the market price on IPv4 addresses peaks and try to sell them for monetary gain.
They can act in the best common interest and hold onto the addresses until they find a way those address could be used to ease the transition from IPv4 to IPv6 for everybody.
So they are claiming that they have nearly 18 million unique devices to manage?
Do you think they are able to achieve a 100% HD Ratio? If they are, that must mean they have more capable people working there than in all the other companies in the communication industry. If I was to name a company that was attracting all the talent in the industry, Virgin Media was not one I was going to think of.
More likely they have an HD Ratio in the 80-90% range just like the rest of the industry. Let's do the numbers again with that kind of HD ratio. In 10.0.0.0/8 you have 24 bits to make use of. With an HD Ratio in the 80-90% range you end up with effectively utilizing 20 or 21 bits. That means 1-2 million devices, not 18 million devices.
Instead of just working with 10.0.0.0/8 let's take the larger sum you mentioned. 17891328 and an HD ratio of 80% gives us 17891328^0.8=634036 and with an HD ratio of 90% it gives us 17891328^0.9=3368048. So we end up with somewhere between 0.6 and 3.4 million devices depending on how much administrative overhead you can tolerate.
We're already having an issue with plans being "too complicated", this would blow our customers' minds.
You don't have to write every implementation detail in the advertisement. The advertisement could simply say "up to 100Mbit/s guaranteed 1Mbit/s available" or "100Mbit/s, maximum 10GB/week". The implementation details could be in the small print that nobody reads and understands anyway. Or they could not even write the implementation details in the contract but put them somewhere on their website. Actually for the throttling to do something sensible, the users don't even have to know the implementation details.
Still telling the users something which is true but too complicated to understand is still better than outright lying to the users. Promising the users more than you are ever going to deliver just because you can word it simpler is not ok. For example setting up the line as I described but call it 100Mbit/s in the advertisement and not mention the throttling that happens when you exceed 1Mbit/s on average would be lying. Calling it a 1Mbit/s line in the advertisement would be better, but wouldn't get you any customers since they would go with the competitor who were lying about their product to sell more subscriptions. But it is not that hard to state both an average speed and a burst speed and then deliver. I wish some providers would take the effort to ensure their own advertisement is honest and then start taking actions against those competitors who gets an unfair advantage by misleading advertisement.
The QoS suggestion doesn't need to be in the advertisement either. It does need to be published such that software developers can make sure to use the proper QoS class by default. If providers would do the right thing with QoS bands, and developers knows that they do, then software developers have an incentive to make their software use the proper QoS class, and users have no incentive to try to override it.
They would rather keep everything nebulous and get clients by who picks the better advertising campaign instead of better service.
As long as they can get away with dishonest advertisement, this is not going to change. If dishonest advertisement is legal you need to change the laws.
its a bit daft to think that every subscriber uses 100% of their bandwidth 24/7, so why not oversell it? After all, if I use 10% of my total bandwidth, there's no reason why you can't allocate that to 9 more subscribers, thus bringing the price down to 1/10th of what it was.
This would work great if they made throttling to actually match the principles you describe, and then advertise the lines as such.
For example they could advertise a line as 100Mbit/s maximum speed, 1Mbit/s average speed. As long as you stay below 1Mbit/s averaged over a week, you will get your 100Mbit/s. If your average over a week goes above 1Mbit/s though, then your maximum speed will start decreasing. Once your weekly average hits 2Mbit/s your maximum speed will have decreased to 1Mbit/s, which is sure to get your weekly average down again.
They could improve it even more by allowing users to put their traffic into different QoS bands, and ensure that they provide incentives for users to use appropriate QoS bands for the traffic they are sending. I think the following three QoS classes would make sense for most users.
Default QoS. In this class you get to transfer as much data as specified by your subscription. It is intended for webbrowsing, email, and most other more or less interactive usages. The providers should guarantee that there is capacity to give you the bandwidth you paid for in this class.
Latency sensitive QoS. In this class you only get to transfer one third of the amount of data specified by your subscription. It is intended for VOIP, action games, and other applications where latency is the important factor. On the routers this traffic needs to go into a special queue. That queue should be short since this traffic is very sensitive to latency. That will increase packet loss a bit, but for some latency sensitive applications packet drops are less of a problem than increased latency. Since this class by design should never ever use more than one third of the capacity of any link, packet drops should be rare anyway.
Bulk QoS. In this class you get to transfer as much data as you want, it doesn't count towards your usage, and you don't get throttled for using too much. OTOH traffic in this class is not guaranteed at all. It only gets what is left over when the above two classes have gotten what they need. This would be useful for downloads lasting hours or days. Probably most traffic in this class would be bittorrent.
I think a classification as described above would give users sufficient incentive to use the proper class for their traffic, and providers don't have to pretend to know better and reclassify the traffic.
But that does not mean that in all puzzles with more than 17 clues you can remove a clue and still have a unique solution.
No. If you first fill in all 81 numbers with a random choice among the valid possibilities and then remove clues in a random order as long as you can do so without making the puzzle ambiguous, then you will usually end up with 24 or 25 numbers where none can be removed without making it ambiguous. That also explains why the ones you usually see have that number of clues.
But there are more questions to be asked. I have written code to generate sudokus using the above algorithm. I end up with between 22 and 28 numbers, though most of the time it is 24 or 25. But ending up with twentysomething numbers depends on the order I removed numbers. Maybe if I removed them in a different order, I would have been able to remove more. So can every combination of the full 81 fields be reduced to just 17 if you just find the right 64 to remove? If not what is the maximum number that would be required? And is there an efficient algorithm to find the smallest possible number of clues for a specific combination of the 81 numbers?
if there were any scarcity of IPv4 addresses the prices would be higher
The RIPE pool is not empty yet, and if the statistics linked above is right, it will be another 7 months before hitting the last/8. What that means is that the number of IP addresses that ISPs can get from RIPE, and the price they have to pay for them is set by a policy which does not take availability into account. As long as ISPs can document that they are using the IP addresses they have been assigned, they can get more.
From that perspective there is no scarcity yet. But it will come. There is less than 60 million addresses left in the pool. And they will run out. There just isn't any mechanism to drive up the prices before the RIPE pool is empty. That means the price you pay for an IP address will tell you nothing about availability.
The current situation actually give ISPs an incentive to lower the prices they charge for IP addresses. It would drive up their consumption, which does increase the cost of running their network slightly. But they could see it as an investment to get a large share of the remaining pool. At the point the limit is hit and RIPE policy changes, there would be an incentive for ISPs to change their policies as well. At that point what makes sense for the ISPs is to slowly increase the prices they charge.
With the logical price remaining at zero from now until the RIPE pool runs out, the current price will tell you nothing about how close were are to the run out date.
Even if that quarter of people aren't going to use the web anytime soon, Europe is still going to run out of IPv4 addresses in a few months. And still there are countries where no single ISP is selling IPv6 capable connections. As much as it may seem like a good idea to improve infrastructure to allow the remaining Europeans to get online, it is actually more important to get the existing infrastructure upgraded to IPv6. Even if we could magically get the remaining Europeans online with IPv6, they would be 2nd class users if the old infrastructure remains IPv4 only.
And even what may look like a good transition plan can be improved, in which case you may very well end up with 6to4, which we know now, didn't work out.
Yeah. Many people have suggested that IPv6 should have been made compatible with IPv4, but how would they even have made it more compatible than it already is?
One idea could have been to kind of force the deployment by saying that a certain subset of IPv6 addresses were used to make it so that any IPv4 route is also an IPv6 route with a specific prefix and a few bits left at the end for the end site to use instead of NAT. Then the packet could move towards the destination being IPv4 part of the way and IPv6 part of the way. The assumption would be that every link along the way was either IPv4 or IPv6 or both, and the routers at the two ends of the link agree on what they are talking on that link. A dual stack router would have to be able to route the packets between IPv4 only and IPv6 only links.
An idea like that would need a few tweaks to actually be possible. First of all you cannot map all of IPv6 address space into IPv4 address space. So you couldn't actually send the packet over an IPv4 only link unless you encapsulate it in IPv4. So, lets improve the idea by making it such that on IPv4 only links the IPv6 packet is encapsulated in IPv4 and will still make progress towards the destination. But what should the destination IPv4 of such an address be to ensure that it will actually progress towards the destination in place of a few IPv4 only routers along the path. Oh right, we are talking about an implicit IPv6 route build from an IPv4 route, so there is an IPv4 address embedded in the IPv6 address, we can use that as destination, and it will progress towards the proper destination until it reaches an IPv6 router than can decapsulate.
But why decapsulate the packet at the first IPv6 capable router? If it is already encapsulated in IPv4 and the entire path is already an implicit path build from a path towards the IPv4 address which is already in the IPv4 destination. So if we don't decapsulate it, it will make towards the proper destination, and we avoid potential problems caused by decapsulating it on a link we thought was dual stack, but where the other end of that link thought it was IPv4 only. So once it has been encapsulated, just leave it encapsulated until we reach a router where the route it is going to take depends on more bits than where put into the IPv4 destination field.
With the above approach everybody can just set up a dual stack router and even if some of the path is IPv4 only, they can still receive IPv6 packets. But how do we get the IPv6 packets back? If the sender is one which only has an implicit IPv6 address build from an IPv4 address, and the destination has an IPv6 address that was assigned in a different way, how do you know where to route it? Well since the sender only had the implicit address likely it is going to hand it off to an ISP with some IPv4 only routers, so it will have to be encapsulated in IPv4. But what destination IPv4 address are you going to use since the destination IPv6 address isn't an implicit one there isn't an IPv4 address that will send it the right direction.
The solution to route packets towards such a non-implicit IPv6 destination could be to reserve a specific IPv4 address to use for the encapsulation. The idea with this reserved IPv4 address is that it will take the default route on every router until it makes into the core of the network, and once it reaches the first dual stack router, it will be decapsulated and routed down a real IPv6 route.
So starting from the idea to make IPv4 and IPv6 routing compatible such that all IPv4 routes automatically result in an IPv6 route, I have improved on the idea to end up with something that sounds workable. But actually, it sounds awfully similar to 6to4. In fact the only point where the improvements on the idea to make IPv4 and IPv6 compatible differs from 6to4 is t
They could argue that they have all kinds of proprietary secret sauce on their resolvers, along with DNSSEC where applicable, to prevent that from happening, but we can leave that aside for now.
What they should have done is include DNSSEC in the client and make that client open source such that it can be verified that it does indeed validate the lookups. That way OpenDNS would not be able to mess with the lookups, that protects against manipulation with the results both by OpenDNS and by attackers who can exploit vulnerabilities in the OpenDNS servers.
This of course only helps on domains protected using DNSSEC. Another thing they can do to help protect against cache poisoning is to use IPv6 by default when contacting authoritative servers, and randomize the last 64 bits of the IP address. Port number and ID field in the DNS request only provides 32 bits of entropy. If using IPv6 with 64 random bits in the IP address the entropy can be increased from 32 bits to 96 bits which defeats a lot of poisoning attacks.
That leaves IPv4 only domains without DNSSEC as the most vulnerable. Unfortunately that still accounts for a large number of domains. But it does look like more and more authoritative servers are getting IPv6 support, so I guess IPv6 deployment is ahead of DNSSEC deployment.
I'm sure they're no worse than other DNS providers
They are not the worst. But I'd still say OpenDNS is doing stuff that is worse than what users should put up with. Personally I would have been using Google DNS, if it wasn't because of lack of IPv6 support.
they do appear to have options to opt-out of the above behaviour
First of all something like this should be opt-in, not opt-out. Secondly, the DNS protocol doesn't even allow for users to configure this. The only way it could be made configurable by the end user is by running different DNS servers on different IP adresses, with one IP for each possible configuration. OpenDNS doesn't appear to be doing this, so I guess they are instead using some unreliable method based on an assumption about a 1:1 mapping between users and client IP addresses. That would work if every user had a static IP address and nobody was using NAT.
Using an IP address per possible configuration wouldn't even be much of a problem since they probably have allocated a/24 for an anycast address anyway. That means they have a total of 8 bits for configuration data. Is the configuration more complicated than what could be encoded using 8 checkboxes?
For me the important point isn't to hide addresses that are being looked up, but to determine the credibility and integrity of the response I receive. Encryption is about more than just hiding data.
Hiding the domain name may help protecting against censorship. There are places where DNS requests are censored. Even if the packets are integrity protected, it doesn't stop an ISP from just dropping every lookup or response for domain names they want to censor.
Sometimes I get the feeling that security updates can in most cases cause more problems than the issues themselves.
Some vendors will push security updates and other updates through the same channel, sometimes even without the user knowing if a particular update is fixing a security problem. Occasionally the update will even be installed without the user's accept.
If it was just a matter of only installing updates to fix known security problems and no other changes were made to the software, I think cases of an update causing a problem would be much smaller.
So we should just ignore Google's blatant violation of GPL?
If you think there is a violation, then document it.
First of all creating a modified version of a piece of GPL software without releasing it is permitted by the license. The license boils down to the requirement that if you release any of the code, you have to release the source as well. But that requirement is hard to violate with header files. If you release the header files, you have released the source since those header files are source code. If you don't release anything, then you are not required to release anything.
There would be a violation if you compiled the code and released just the compiled version. In that case it doesn't even matter if you modified them or not. But you don't compile header files, you compile c files. The c files may include header files. However compiling c code that uses a header file doesn't mean that you are copying the header file. The object file is a translation of the c file, the header file merely aids the compiler in the translation.
You can construct a header file in a way that it actually contains a copyrightable piece of code that gets copied to the resulting object file. But that is not how header files are supposed to be used. If you construct such a header file and then sue over somebody compiling against it, then you are responsible for abusing header files in the first place, and whoever compiled against it were acting in good faith.
In short header files are copyrightable, but that doesn't turn the compiled code into a derivative work of the header file.
So tell us what it is you think Google has done, which they are not allowed to? Modifying a header file isn't enough.
Slashdot Mirror
That is not exactly correct. If you use netcat newlines are not send in the correct way. The nc command will receive character number 10 from the terminal and write character number 10 on the socket. However text based protocols don't use character number 10 for newlines, they use character number 13 followed by character number 10.
That means if you use the nc command to connect to a server with just about any text based protocol, you will be sending malformed commands. However many servers will accept what you send anyway and simply do the exact same thing when they see a character number 10 as they would have done if they had seen character number 13 followed by character number 10.
OTOH using the telnet command to connect to a server with a text based protocol will do the right thing. The telnet command will send the proper 13 followed by 10 sequence when you press enter.
It is true that what telnet does in this case is nothing like the telnet protocol. As a matter of fact, the telnet protocol is not a text based protocol. The telnet client will recognize the difference because a real telnet server will send some binary data immediately when a connections is established.
So to talk a text based protocol using the telnet client is a better choice. If you are going to be using a binary protocol, nc is more suitable (but of course then stdin and stdout should of course not be a terminal). One problem that nc still has is that it doesn't properly handle half open connections correctly, not that I think telnet is any better, it is just that when pushing raw data over a TCP socket, nc is my usual choice, and in those cases half open connections matter.
Speaking of ssh tricks, I wrote this tool a few years back to allow the ssh client to choose from multiple alternative ways to connect to an ssh server.
Actually that's not correct. Where you say more likely, you should instead have said slightly less likely. But that is assuming the key generation algorithm generated random primes. In reality the primes being generated are not truly random. And that flaw in how the keys are generated is the whole point of the article.
The second point of the article is that you don't need to fully understand the flaw in order to exploit it. They had a hunch and tried it out. Computing GCD between every pair of keys is the obvious approach, but I would have thought that would be infeasible due to the extremely large number of pairs to be considered. And they did in fact make some optimizations in order to speed up the computation. It does look like their algorithm is still quadratic time in the number of keys, but it may have smaller complexity with respect to the key size.
Managing to identify all the repeated primes is quite impressive.
Once you have identified that the problem is real, and which devices are affected, a determined attacker could try to identify all the primes that could be generated by that class of device. You actually just need the first of the two primes. As explained in the article the first prime tend to be less random, and knowing one of the two, you can compute the other.
And those companies are causing an unnecessary risk to all the reasonable companies. I think for the majority of people, the first reaction when finding a security hole is to find out how to contact the persons responsible for it in order to get it fixed. How many times will a person do that if the reaction is either being ignored or being threatened with a lawsuit? I don't think many people will keep being helpful if that gets them such threats, and I think most people will stop the first time when they get such a threat.
So some people will just start ignoring the security holes, and others will start thinking about other ways that knowledge could be used. Some of those may come up with various sorts of abuse as the other way it could be used. If reports about security holes were handled in a reasonable fashion by the majority of companies and never resulted in threats against the person who reported it, then there would have been an overwhelming chance that it would be found by an honest person and reported before it was found by somebody wishing to abuse it. But those unreasonable companies are keeping most of the honest people silent and turning the rest to think in a less honest way. They are increasing the risk to the entire industry.
I'm curious how the case would turn out in court if a security hole was found in a completely innocent way, and the person who found it decided to publish details on the security hole after the irresponsible company had tried to threaten that person to silence because they didn't want to spend resources on fixing their stuff.
I'll me propose an actual API that could be used for this. First of all the master key is encrypted with two layers of encryption. First it is encrypted using RSA, next it is encrypted again using the password. The RSA encryption step needs a bit of extra work to make the encryption indistinguishable from a sequence of random bits. By default an RSA encryption doesn't look exactly like random bits. The point is that the RSA encryption is from an interval [0;n[, where n is the product of two large primes. Since n is not a power of two, not all possible combinations of the bits will result in a value in that interval. But after performing an RSA encryption you can just add a random multiple of n to the value, and that essentially solves that part. Once you have made that minor step between encrypting using RSA and encrypting using password, it will be such that no matter which password you try, you cannot know if that password was correct until you have done the RSA decryption as well. The RSA secret key is on the server, the RSA public key is stored in clear on the encrypted disk.
Decryption happens using this protocol:
The HMAC key is completely unrelated to the actual encryption key. The server knows the RSA secret key and the HMAC key. All the server will ever know was that a request was made and if the validity of the request was subsequently proven to be valid. The server learns nothing about the key material. As a matter of fact, a completely valid session of this protocol could be produced using only the key material on the server.
True. If they were to return any addresses at all, they can no longer announce a route to 18.0.0.0/8. (I don't know if they do announce it like that, but having a class A, they could). If they can no longer announce a /8 they would have to announce smaller blocks. If they were able to squeeze everything into half the addresses they have now, then they could announce a /9 and return the other /9. If that is not possible, then they would be forced to announce their addresses as multiple prefixes and thereby increase the global routing table size and cause problems for everybody else.
/8 and would want to return some, you shouldn't do so unless you really think it is feasible to squeeze all your usage into half the space you used to have. You also need to ensure that whatever address space you are left with is enough to last until everybody else have switch to dual stack (or IPv6 only). Since the purpose of returning addresses is to prolong the transition (which isn't much of a useful purpose), it also implies that the more addresses you return, the longer those you have left will have to last. That's not much of an incentive to return addresses.
If you have a
Apart from BGP is it really much of a problem to return just small fragments of address space? Do you have to change your network, if you weren't using those addresses anyway? The answer to that question of course is yes. If you were to just change your BGP announcements to stop announcing some addresses that you weren't using anyway, nothing would break yet. However if you were to return them and they got reassigned, things would break, if you had only changed your BGP announcements.
The reason things would break is that the route to those addresses would still end up somewhere inside the same network, if it originated there. Taking your example, a packet from 18.127.1.2 to 18.128.2.3 would never leave the MIT network even if the destination address had been returned, because the routers inside the MIT network would still think it was a destination within their network. It would propagate through their network until a point where some router would report no route to host. So both the BGP announcements and the routing inside the network would have to be redone before addresses could be returned.
Even once they have everything set up as dual stack, they would still want to keep IPv4 for as long as there was anybody else on IPv4 only who they wanted to communicate with. The point at which it makes sense to return the IPv4 addresses to ARIN is also the point at which nobody else would want them anymore. It is not like the demand for IPv4 addresses would drop to zero overnight, but it is probably going to be close to it.
Most likely we will eventually reach a point where nobody would bother to setup new IPv4 networks, and the demand for addresses will decrease. The decrease in demand will not be very visible since there won't be much of a supply either. But those who are already dual stack won't turn down their IPv4 support right away. Just as their isn't much to gain from turning up IPv4 when everybody else is dual stack, there won't be much to gain from turning down IPv4 support.
At a later date the work to keep administrating IPv4 in parallel with IPv6 will be more significant than the work it will take to remove the last few IPv4 dependencies. At that point people will turn down IPv4 and return the addresses. And nobody will care about the returned addresses.
That is not the way forward either. Such a redirect would work for all those people that don't need it, and it would fail for those people that do need it.
The main domain should be available over both IPv4 and IPv6. Each client use whatever it has. The problem with that is that some networks are misconfigured, and some software doesn't do fall back to another protocol very well.
ipv4.google.com already exists for those people who have a misconfigured connection. I think it was set up prior to IPv6 day last year, and it will probably stay around for many years to come. But a redirection like you suggest won't work for those people with a broken connection because you cannot send a redirect back to a client that is unable to contact the server in the first place. For the majority of users where things just work that redirect would work, but it wouldn't be desired. The goal is for the transition to happen with the majority of the users never noticing a difference. A period where all IPv4 only users get redirected to a different domain doesn't achieve that.
Had clients that defaults to IPv6 had good fallback to IPv4 to begin with, then we wouldn't have had the need for separate domains, redirects, DNS whitelists, IPv6 day, etc. We would have seen content available over IPv6 2-3 years earlier than we do now.
I don't use Windows, so I didn't know about that bug. But I would say Microsoft should go and fix that bug. And if Microsoft won't fix that bug, then you should consider using a different operating system, that doesn't suffer from said bug.
The correct implementation of privacy extension would by default do the following: At system boot each interface is assigned two link local addresses as well as two IPv6 addresses per router advertised on that network segment. One of the two addresses would be based on the MAC address and hence be static, the other address would be randomly generated (according to the spec). Incoming connections can use any of the IP addresses. Outgoing connections will use the randomly generated address (unless the application explicitly overrides that choice by binding to a different address). Every 24 hours more randomly generated addresses are added, again one link local address per interface plus one per router advertised on that network segment. The new randomly generated addresses are made default. The old randomly generated addresses remain on the interface until they are no longer in use, and only then they are removed.
If Windows didn't suffer from the bug you mentioned, then it would notice that there was an open TCP connection using that old address and thus would keep it on the interface even though it wasn't the default for new outgoing connections anymore.
And when I said that the above should be the default, it should of course allow the user to configure it. For example the 24 hour interval could be configurable. In addition there is a few possible tweaks. For example you might not need privacy extension on link local addresses. It will be of limited use since for a link local connection the other endpoint can see the MAC adress anyway. In addition the 24 hour interval could be made in a way that doesn't synchronize the adding of new addresses. If you have two interfaces and receive two prefixes on each of those there is no need to update all four addresses at the same time. Doing it at the same time might reveal some information to the peers you are communicating with, and it will also reveal information about your uptime. Instead the first assigned address is given a lifetime chosen uniformly between 1s and 24h. After that it is updated every 24h.
I tried to do similar calculations a little while back and came up with 2020 as the time we would run out. So I think your calculations are right, the one year difference just means a bit of uncertainty. Another way to interpret the result of this calculation is that by 2019 there will be more devices on IPv6 only than the total number of devices that will fit in IPv4.
Some DNS servers are worse than that. They will not only fail to lookup the AAAA record, but in the process of attempting, they will put garbage into their cache and cause subsequent A lookups for the same domain to return an incorrect IP address.
They may have lasted two months if they were returned a year ago. But if they were returned today, they would be consumed as quickly as APNIC could file a request. Extrapolating the usage trend in the APNIC region from before the pool ran out suggests that they by now could file a request for 10 /8 networks to meet actual demand.
We are well past the point where returning addresses will do any good. They will be consumed just as quickly as they are returned, and doing so will fragment allocations even more leading to an explosion in the routing table size.
Those who actually have unused addresses, which they could return have a few options:
But most likely only a few million of those could be returned.
Do you think they are able to achieve a 100% HD Ratio? If they are, that must mean they have more capable people working there than in all the other companies in the communication industry. If I was to name a company that was attracting all the talent in the industry, Virgin Media was not one I was going to think of.
More likely they have an HD Ratio in the 80-90% range just like the rest of the industry. Let's do the numbers again with that kind of HD ratio. In 10.0.0.0/8 you have 24 bits to make use of. With an HD Ratio in the 80-90% range you end up with effectively utilizing 20 or 21 bits. That means 1-2 million devices, not 18 million devices.
Instead of just working with 10.0.0.0/8 let's take the larger sum you mentioned. 17891328 and an HD ratio of 80% gives us 17891328^0.8=634036 and with an HD ratio of 90% it gives us 17891328^0.9=3368048. So we end up with somewhere between 0.6 and 3.4 million devices depending on how much administrative overhead you can tolerate.
You don't have to write every implementation detail in the advertisement. The advertisement could simply say "up to 100Mbit/s guaranteed 1Mbit/s available" or "100Mbit/s, maximum 10GB/week". The implementation details could be in the small print that nobody reads and understands anyway. Or they could not even write the implementation details in the contract but put them somewhere on their website. Actually for the throttling to do something sensible, the users don't even have to know the implementation details.
Still telling the users something which is true but too complicated to understand is still better than outright lying to the users. Promising the users more than you are ever going to deliver just because you can word it simpler is not ok. For example setting up the line as I described but call it 100Mbit/s in the advertisement and not mention the throttling that happens when you exceed 1Mbit/s on average would be lying. Calling it a 1Mbit/s line in the advertisement would be better, but wouldn't get you any customers since they would go with the competitor who were lying about their product to sell more subscriptions. But it is not that hard to state both an average speed and a burst speed and then deliver. I wish some providers would take the effort to ensure their own advertisement is honest and then start taking actions against those competitors who gets an unfair advantage by misleading advertisement.
The QoS suggestion doesn't need to be in the advertisement either. It does need to be published such that software developers can make sure to use the proper QoS class by default. If providers would do the right thing with QoS bands, and developers knows that they do, then software developers have an incentive to make their software use the proper QoS class, and users have no incentive to try to override it.
As long as they can get away with dishonest advertisement, this is not going to change. If dishonest advertisement is legal you need to change the laws.
This would work great if they made throttling to actually match the principles you describe, and then advertise the lines as such.
For example they could advertise a line as 100Mbit/s maximum speed, 1Mbit/s average speed. As long as you stay below 1Mbit/s averaged over a week, you will get your 100Mbit/s. If your average over a week goes above 1Mbit/s though, then your maximum speed will start decreasing. Once your weekly average hits 2Mbit/s your maximum speed will have decreased to 1Mbit/s, which is sure to get your weekly average down again.
They could improve it even more by allowing users to put their traffic into different QoS bands, and ensure that they provide incentives for users to use appropriate QoS bands for the traffic they are sending. I think the following three QoS classes would make sense for most users.
I think a classification as described above would give users sufficient incentive to use the proper class for their traffic, and providers don't have to pretend to know better and reclassify the traffic.
No. If you first fill in all 81 numbers with a random choice among the valid possibilities and then remove clues in a random order as long as you can do so without making the puzzle ambiguous, then you will usually end up with 24 or 25 numbers where none can be removed without making it ambiguous. That also explains why the ones you usually see have that number of clues.
But there are more questions to be asked. I have written code to generate sudokus using the above algorithm. I end up with between 22 and 28 numbers, though most of the time it is 24 or 25. But ending up with twentysomething numbers depends on the order I removed numbers. Maybe if I removed them in a different order, I would have been able to remove more. So can every combination of the full 81 fields be reduced to just 17 if you just find the right 64 to remove? If not what is the maximum number that would be required? And is there an efficient algorithm to find the smallest possible number of clues for a specific combination of the 81 numbers?
The RIPE pool is not empty yet, and if the statistics linked above is right, it will be another 7 months before hitting the last /8. What that means is that the number of IP addresses that ISPs can get from RIPE, and the price they have to pay for them is set by a policy which does not take availability into account. As long as ISPs can document that they are using the IP addresses they have been assigned, they can get more.
From that perspective there is no scarcity yet. But it will come. There is less than 60 million addresses left in the pool. And they will run out. There just isn't any mechanism to drive up the prices before the RIPE pool is empty. That means the price you pay for an IP address will tell you nothing about availability.
The current situation actually give ISPs an incentive to lower the prices they charge for IP addresses. It would drive up their consumption, which does increase the cost of running their network slightly. But they could see it as an investment to get a large share of the remaining pool. At the point the limit is hit and RIPE policy changes, there would be an incentive for ISPs to change their policies as well. At that point what makes sense for the ISPs is to slowly increase the prices they charge.
With the logical price remaining at zero from now until the RIPE pool runs out, the current price will tell you nothing about how close were are to the run out date.
Even if that quarter of people aren't going to use the web anytime soon, Europe is still going to run out of IPv4 addresses in a few months. And still there are countries where no single ISP is selling IPv6 capable connections. As much as it may seem like a good idea to improve infrastructure to allow the remaining Europeans to get online, it is actually more important to get the existing infrastructure upgraded to IPv6. Even if we could magically get the remaining Europeans online with IPv6, they would be 2nd class users if the old infrastructure remains IPv4 only.
Yeah. Many people have suggested that IPv6 should have been made compatible with IPv4, but how would they even have made it more compatible than it already is?
One idea could have been to kind of force the deployment by saying that a certain subset of IPv6 addresses were used to make it so that any IPv4 route is also an IPv6 route with a specific prefix and a few bits left at the end for the end site to use instead of NAT. Then the packet could move towards the destination being IPv4 part of the way and IPv6 part of the way. The assumption would be that every link along the way was either IPv4 or IPv6 or both, and the routers at the two ends of the link agree on what they are talking on that link. A dual stack router would have to be able to route the packets between IPv4 only and IPv6 only links.
An idea like that would need a few tweaks to actually be possible. First of all you cannot map all of IPv6 address space into IPv4 address space. So you couldn't actually send the packet over an IPv4 only link unless you encapsulate it in IPv4. So, lets improve the idea by making it such that on IPv4 only links the IPv6 packet is encapsulated in IPv4 and will still make progress towards the destination. But what should the destination IPv4 of such an address be to ensure that it will actually progress towards the destination in place of a few IPv4 only routers along the path. Oh right, we are talking about an implicit IPv6 route build from an IPv4 route, so there is an IPv4 address embedded in the IPv6 address, we can use that as destination, and it will progress towards the proper destination until it reaches an IPv6 router than can decapsulate.
But why decapsulate the packet at the first IPv6 capable router? If it is already encapsulated in IPv4 and the entire path is already an implicit path build from a path towards the IPv4 address which is already in the IPv4 destination. So if we don't decapsulate it, it will make towards the proper destination, and we avoid potential problems caused by decapsulating it on a link we thought was dual stack, but where the other end of that link thought it was IPv4 only. So once it has been encapsulated, just leave it encapsulated until we reach a router where the route it is going to take depends on more bits than where put into the IPv4 destination field.
With the above approach everybody can just set up a dual stack router and even if some of the path is IPv4 only, they can still receive IPv6 packets. But how do we get the IPv6 packets back? If the sender is one which only has an implicit IPv6 address build from an IPv4 address, and the destination has an IPv6 address that was assigned in a different way, how do you know where to route it? Well since the sender only had the implicit address likely it is going to hand it off to an ISP with some IPv4 only routers, so it will have to be encapsulated in IPv4. But what destination IPv4 address are you going to use since the destination IPv6 address isn't an implicit one there isn't an IPv4 address that will send it the right direction.
The solution to route packets towards such a non-implicit IPv6 destination could be to reserve a specific IPv4 address to use for the encapsulation. The idea with this reserved IPv4 address is that it will take the default route on every router until it makes into the core of the network, and once it reaches the first dual stack router, it will be decapsulated and routed down a real IPv6 route.
So starting from the idea to make IPv4 and IPv6 routing compatible such that all IPv4 routes automatically result in an IPv6 route, I have improved on the idea to end up with something that sounds workable. But actually, it sounds awfully similar to 6to4. In fact the only point where the improvements on the idea to make IPv4 and IPv6 compatible differs from 6to4 is t
That's not how IPv4.1 works. Check the facts.
What they should have done is include DNSSEC in the client and make that client open source such that it can be verified that it does indeed validate the lookups. That way OpenDNS would not be able to mess with the lookups, that protects against manipulation with the results both by OpenDNS and by attackers who can exploit vulnerabilities in the OpenDNS servers.
This of course only helps on domains protected using DNSSEC. Another thing they can do to help protect against cache poisoning is to use IPv6 by default when contacting authoritative servers, and randomize the last 64 bits of the IP address. Port number and ID field in the DNS request only provides 32 bits of entropy. If using IPv6 with 64 random bits in the IP address the entropy can be increased from 32 bits to 96 bits which defeats a lot of poisoning attacks.
That leaves IPv4 only domains without DNSSEC as the most vulnerable. Unfortunately that still accounts for a large number of domains. But it does look like more and more authoritative servers are getting IPv6 support, so I guess IPv6 deployment is ahead of DNSSEC deployment.
They are not the worst. But I'd still say OpenDNS is doing stuff that is worse than what users should put up with. Personally I would have been using Google DNS, if it wasn't because of lack of IPv6 support.
First of all something like this should be opt-in, not opt-out. Secondly, the DNS protocol doesn't even allow for users to configure this. The only way it could be made configurable by the end user is by running different DNS servers on different IP adresses, with one IP for each possible configuration. OpenDNS doesn't appear to be doing this, so I guess they are instead using some unreliable method based on an assumption about a 1:1 mapping between users and client IP addresses. That would work if every user had a static IP address and nobody was using NAT.
/24 for an anycast address anyway. That means they have a total of 8 bits for configuration data. Is the configuration more complicated than what could be encoded using 8 checkboxes?
Using an IP address per possible configuration wouldn't even be much of a problem since they probably have allocated a
Hiding the domain name may help protecting against censorship. There are places where DNS requests are censored. Even if the packets are integrity protected, it doesn't stop an ISP from just dropping every lookup or response for domain names they want to censor.
Some vendors will push security updates and other updates through the same channel, sometimes even without the user knowing if a particular update is fixing a security problem. Occasionally the update will even be installed without the user's accept.
If it was just a matter of only installing updates to fix known security problems and no other changes were made to the software, I think cases of an update causing a problem would be much smaller.
If you think there is a violation, then document it.
First of all creating a modified version of a piece of GPL software without releasing it is permitted by the license. The license boils down to the requirement that if you release any of the code, you have to release the source as well. But that requirement is hard to violate with header files. If you release the header files, you have released the source since those header files are source code. If you don't release anything, then you are not required to release anything.
There would be a violation if you compiled the code and released just the compiled version. In that case it doesn't even matter if you modified them or not. But you don't compile header files, you compile c files. The c files may include header files. However compiling c code that uses a header file doesn't mean that you are copying the header file. The object file is a translation of the c file, the header file merely aids the compiler in the translation.
You can construct a header file in a way that it actually contains a copyrightable piece of code that gets copied to the resulting object file. But that is not how header files are supposed to be used. If you construct such a header file and then sue over somebody compiling against it, then you are responsible for abusing header files in the first place, and whoever compiled against it were acting in good faith.
In short header files are copyrightable, but that doesn't turn the compiled code into a derivative work of the header file.
So tell us what it is you think Google has done, which they are not allowed to? Modifying a header file isn't enough.