Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Not perfect, but it's a start... (Score 1) 279

Security means encryption + integrity + authentication.

Why? Why should this be the standard for "security"?

Because so far it's the best we have. And because security is only as strong as the weakest link.
You seem, however, to disagree. What would, in your opinion, be a reasonable standard for end-to-end security?

I'm not sure what you mean by Mozilla "blacklisting" basic encryption. As far as I know, self-signed certs work just fine in Mozilla. With a warning, of course - as it should be (and IMHO, that warning should be much stronger than it already is).

Just don't highlight self signed certs with a yellow lock bar was all anyone could want

You seem to forget that the web is not only visited by people like you, me, and most of the /. crew. Average Joe doesn't know how to look at the lock bar, and he doesn't know how to check if a certificate is valid. And this makes him the point where encryption without trust falls apart.

And since you seem intent on throwing NSA around - while it may be easier for them to just sniff traffic, they really have no problem in mounting a MITM attack (see links in my previous post). And while it has not been proven yet, they might just as well have the ability to generate their own certificates, trusted by the major browser vendors (see here - but again, keep in mind that this is just speculation at the moment).

So even if we have encryption+authentication, it still may not be enough. Not when faced with an attacker which has the resources to break the chain of trust.

I won't even get started on the fact that the NSA has knowingly attempted to compromise encryption standards. :)

Comment Re:Not perfect, but it's a start... (Score 1) 279

I forgot to answer your question...

Let me ask you directly: Do you believe that a person trusting a self-signed cert is less secure than a person using an unencrypted connection?

No. I never said that it is less secure. I said that once you start blindly accepting self-signed SSL certificates, you are no longer secure. Maybe not as insecure as with clear text, but definitely not too far away from it.

Comment Re:Not perfect, but it's a start... (Score 1) 279

I will grant you the fact that unencrypted connections are vulnerable to both sniffing and MITM, while self-signed certs are "only" vulnerable to MITM. But you seem to believe that there is a huge leap from sniffing to mounting a MITM - and this is where we disagree. While MITM may incur an additional cost for the attacker, it is far from being an unrealistic scenario (see below for some examples).

As for the rest of your rant^H^H^H^H post, it doesn't really make sense. You believe that a self-signed certificate will somehow "protect" you from the NSA? Who is somehow incapable of a MITM? Well, this, this and this may prove... enlightening. And while we're on the topic of "additional reading", may I also recommend "Alice in Warningland" - a study showing 70+% clickthrough rates for SSL warnings.

There are some other issues, like you mentioning wireless traffic. With WPA2 being the default, and with many modern wireless NICs no longer supporting promiscuous mode, it is often more difficult to sniff wireless traffic than to mount a MITM on a wired network (especially when the target is the victim's router - again, see the links above).

Security means encryption + integrity + authentication. Period. Anything less is no longer secure.

Comment Not perfect, but it's a start... (Score 4, Insightful) 279

So basically all this does is to force HTTPS requests instead of HTTP? (took me a while to find out - gotta love the fact that the "clever technology" link on their site, instead of going to a description of the actual technology, goes to... xkcd?! :) )

I see a few problems with this approach:
1)Not all content is provided over both HTTP and HTTPS. For multiple reasons, one being performance. Which leads us to the second problem...
2)A HTTPS session incurs a significant overhead for encryption. Which may be no problem for someone like Google. But for someone hosting his/her own (moderately successful) website on a small server, it might just overload said server.
3)Quite possibly the biggest problem with HTTPS is the fact that users have been trained over many years to just click "accept/install certificate" on self-signed certs. Not knowing that if you do this you are no longer secure.

And the more we keep forcing HTTPS, the more webmasters will use self-signed certs. Not many people want to go through the hassle of obtaining (and maintaining!) a valid SSL certificate for every single website they run, even if that cert is free. Which will only exacerbate the problem...

Submission + - UPlay Accounts Hacked (ubi.com)

bogd writes: According to an e-mail recently sent out by Ubisoft, a series of UPlay accounts have been compromised (usernames, email addresses, encrypted passwords — but not payment information). The e-mail urges users to reset their UPlay passwords and "change the password on any other Web site or service where you use the same or a similar password". The site shows up as "under maintenance", but the official announcement is here.

Not the best kind of publicity to have when you require always-on DRM for your games...

Comment Re:IPv6 isn't the solution (Score 1) 327

It was designed to be transitioned to gradually.

Nope. For all the reasons I explained to you previously, chief being the fact that IPv6 is 100% incompatible with IPv4 on the wire.

Tunnels were expected to be part of the transition.

True. And just as true is the fact that tunnels only solve half the problem. Yes, they help getting new IPv6 hosts to talk to each other (over a potentially non-IPv6 compliant infrastructure). But they do not solve the bigger issue - getting new IPv6 hosts to talk to existing IPv4-only hosts (like, I don't know... the entire Internet?!).

IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4.

And once again, I strongly suggest that you should read and understand the term "compatibility". I'll give you a hint: "just use the old protocol at the same time" isn't it!

Why is this insufficient?

Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.

In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?

And in the second case, there's no way to do dual stack anymore - and where's your "simple mechanism" then?

I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky :) ).

Comment Re:IPv6 isn't the solution (Score 1) 327

I came to the conclusion that doing backwards compatibility the way BGP does it would be similar to the IPv4/IPv6 case if every v4 host was already aware of how to do 6to4.

In one of my previous posts, I linked to the definition of http://en.wikipedia.org/wiki/Backward_compatibility. You either didn't read it, or didn't understand it - the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it.

I'm not saying that the exact same solution that was applied for BGP could be used for IP. They are completely different protocols, with different sets of rules. I just gave you two examples of what real compatibility looks like, since you still seem to believe that 6to4 offers it.

IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count.

By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.

That is how we're doing the transition from a v4-only internet to a v6-only internet though. I'm not sure what else I can call it.

Totally agree with you - it's basically the only solution we have right now. But the fact that it's the only solution doesn't make it a good one. Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.

And before you say "no problem, at that point we'll just turn off IPv4!", keep in mind that this will not be possible until there is no IPv4 Internet to speak of. How long do you think that will be? My guess would be on the order of decades...

That's a big "if"... but the answer is "because it saves you resources and manpower".

A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails.

And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything? Please don't forget that we are talking about the transition here - that transition being done by using dual stack.

Comment Re:IPv6 isn't the solution (Score 1) 327

Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.

Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).

This is called actually the important part of the transition strategy. And it is completely missing in IPv6.

That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.

And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".

No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.

I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.

OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack"

No need for sarcasm - I really don't feel the need for this to degenerate into a flame war. You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.

And yes, dual stack does exactly that - run two separate networks, totally separate from each other ("ships in the night"). And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary (your misnamed "transition period"), and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?

Comment Re:IP6 addresses are a pain (Score 1) 327

The right-most octet in the abbreviated address substitutes for the right-most octets of the full address.

Do you have a reference for that? I did notice the behavior in operating systems ("ping 127.1" translates to "ping" in both Windows and Linux), but I was never able to find an RFC that talks about it.

Comment Re:IPv6 isn't the solution (Score 1) 327

There is no capability in IPv6 for a routing table. That goes away.

No it doesn't. And it cannot. There still is a routing table, it's just... bigger :) (not that big as you would expect though, due to the larger subnets and better aggregation. In theory, at least).

In fact, one of the major selling points of IPv6 is that the subnetting and routing remain the same as in IPv4 (making things a bit easier to understand for administrators).

So if I'm sending a packet to you in v6 and we disagree on 37 bits there are 37 virtual routers (there may be more one virtual router implemented on a physical router) between you and I exactly.

That makes no sense to me. Do you have any kind of reference for the idea that "a bit in the address = a virtual router"?

IPv6 A wants to talk to IPv4 B:

1) A gets a dynamic IPv4 addresses assigned to it (unless (4) below).

Congratulations - your IPv6-only is now also an IPv4 host! That does not solve the original problem - getting an IPv6-only host to talk to an IPv4-only host. Aka "compatibility".

What is not the case though, what started the discussion with GP is that every v6 address is reachable by v4. As traffic moves to v6, a smaller percentage of v6 services will be offered on the v4 internet, and v4 will become a less and less functional subset of the internet. That's good, that's what we want.

I completely agree with you there (see a previous comment of mine). Getting stuff on the IPv6-only Internet might actually persuade a lot of host owners to upgrade.

Until we have an IPv6 Internet however, we need to make sure that people who move to IPv6 can still access the existing IPv4-only services. This is where the v6-to-v4 compatibility is necessary. And that compatibility was completely overlooked.

And no, "just add an IPv4 address to your host" doesn't cut it. If I'm going to have to run IPv4 to access my services, why bother with IPv6 at all?

Comment Re:IPv6 isn't the solution (Score 1) 327

Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6.

I suggest you have a look at the term "backward compatibility", and try to understand what I am talking about. Quote: "a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.".

Simply specifying a version number does NOT make a product backward compatible.

If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).

In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs.

Exactly. Because there is no way you will update the entire Internet (or, on a smaller scale, all the components and legacy applications of an enterprise) all at once. And until you do, you will need your shiny new IPv6-enabled machine to access everything else.

The v6->v4 case is easy enough

No, it isn't (if you do not agree, please feel free to tell me how it is). And please remember that "I'll just put an IPv4 address on it" is not a solution - that will just make it an IPv4 machine as well. And then, why bother adding IPv6 to it??

It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space). Yes, there is more to it than that (you would need gateways capable of "translating" between that prefix and IPv4), but that is one idea.

Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?

Via the pigeon hole principle

Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).

If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem. It might even be an incentive for the host's owner to upgrade :) . But that case will only come into play many years later, when we actually have an IPv6-only internet.

Comment Re:IPv6 isn't the solution (Score 1) 327

In the sense you mean, no it wouldn't. v6 and v4 routers don't work the same way.

Can you elaborate on that? The actual routing process is exactly the same, it's just the headers that are different.

That's standard dual stack.

And "standard dual stack" means having two separate networks - one that only speaks IPv4, and one that only speaks IPv6. With no way to communicate between the two. And this is the real issue.

Comment Re:IPv6 isn't the solution (Score 1) 327

Let's see: one person points (very accurately) one of the main reasons why IPv6 isn't widely deployed at the moment: lack of any kind of backward compatibility with IPv4. He gets modded "0, redundant". Another person mentions 6to4, and gets modded "5, insightful". Looks like the mods have been listening to way too much IPv6 marketing, and are starting to believe it.

Look a little more into the subject, and you will see that 6to4 does not offer backward compatibility in any way, shape or form. It is simply a way for IPv6 "islands" to communicate over an IPv4 network.

The real problem, however, is getting an IPv6-only host to communicate with an IPv4-only host. Until we have that, there is no backward compatibility to speak of. And so far, the only mechanism that can do that (at least partly) is a form of NAT - NAT64. And that is still in its infancy, works only one way (v6 client to v4 server), and brings with it all the disadvantages of NAT (which we are trying so hard to avoid by moving to IPv6).

Even though I do not agree with his solution to the problem (I don't think his multicast solution would have solved the problem), the OP (Alomex) is right - there is no backward compatibility built into IPv6. And this is what has hindered IPv6 adoption from the very beginning.

Slashdot Top Deals

When it is incorrect, it is, at least *authoritatively* incorrect. -- Hitchiker's Guide To The Galaxy