Computing desk
< April 24	<< Mar \| April \| May >>	April 26 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

April 25

Reassignment of state IP addresses

A thread at WP:AN led me to [1] and [2], in which childish vandalism from several years ago has been attributed to UK state-owned IP addresses. Dynamic IP addresses are common for residential customers and schools, but does it ever happen that an IP address could be reassigned from a home or a school to a state agency? I couldn't find anything relevant in the IP address article. Nyttend (talk) 01:20, 25 April 2014 (UTC)[reply]

Large blocks of addresses are assigned to large internet companies, to regional authorities like ARIN, RIPE NCC, etc., and (often for legacy reasons) to a few organisations like universities which were early players on the internet when it began. RIPE etc. then carve off chunks of their space (still in the tens of thousands) for ISPs and large organisations like governments. Unusually, the DWP also has its own /8 block (16 million addresses) as noted by John Graham-Cumming here (I checked RIPE's database just now and it's still assigned). Beyond that, how a large organisation like a government assigns its addresses is its own affair (it's not a public record, necessarily). Usually they'll subnet internally, with final assignments to individual machines a mixture of static (esp for servers) and dynamic (for moving things like laptops). But it's very common for such large organisations to keep their internal network (everyone's workaday machine) behind a firewall which rewrites the address space (a big Network address translation) and with geographic distinctions pretended-away (by a Virtual private network). For the UK that's the Government Secure Intranet, which most people in central government departments use. If someone in the government accesses the public internet, there need be no (permanent) relation between the IP address and an individual workstation; so in practice it will work like an ISP, and possibly (as the ISP in the UAE is) with many people NATed into a handful of public addresses. This means that if it becomes necessary (e.g. for legal reasons) to trace who did a specific action on the internet, from such an address, it would require access to the logs for the firewalls and routers to figure out who. The Guardian article talks about changes made in 2009 - it may be difficult to do that backtracking after such a delay. In any event, even if the change could be ascribed to a specific computer, that's not enough to blame the person who would typically use that machine (everyone has that co-worker who thinks he's such a witty prankster). -- Finlay McWalterᚠTalk 08:41, 25 April 2014 (UTC)[reply]

If you're wondering whether a current GSI address was, in 2009, assigned to an ordinary public ISP - probably not. When big blocks of addresses are assigned, that's usually permanent - the addresses are rare, and organisations don't want to give them up. To delay the IPv4 address crunch, some organisations (e.g. Stanford Uni) have voluntarily given up very large chunks they were formerly assigned. To answer your question for sure, for some specific block, would require digging around in the history of RIPE's assignments to that block - but it's unlikely. -- Finlay McWalterᚠTalk 08:45, 25 April 2014 (UTC)[reply]

I'd hope that the people investigating this case checked that before they checked anything else. If the IPs didn't belong to the government at the time of the edits, I'm sure the articles covering this story would mention that.

In Talk:Hillsborough disaster#Wikipedia edits from government IP addresses an anonymous person says "those two address are firewalls that provide internet access (via network address translation) to pretty much the entire civil service". -- BenRG (talk) 20:42, 25 April 2014 (UTC)[reply]

In any case according to the BBC (second ref above):

the Liverpool Echo reporter who broke the story, said the paper used a list of 34 IP addresses for Whitehall computers, released in 2008 by Angela Eagle MP following a parliamentary question.

So if the Liverpool Echo is to be trusted, these IPs were used by the government in 2008. So the IPs would need to be assigned to the government in 2008 and now but not in 2009 and 2012. (Note that the fact that they were used by Whitehall computers doesn't mean they were only used by Whitehall computers, it could easily be the case that the anonymous IP is correct.)

Nil Einne (talk) 04:17, 28 April 2014 (UTC)[reply]

Login pages not using SSL

Over the past few days, I've noticed a shocking number (six so far) of websites that have login pages that aren't using SSL including two websites who ironically were sending me newsletters promoting articles/webcasts about web security. I've been notifying the websites to let them know that they have a gaping security hole, but so far, have only heard back from one. In any case, I've been wondering to myself why browsers can't detect whether a login page is using SSL. I just noticed that Firebug has such an ability, so obviously, it's possible. So here's my question. Does anyone know of any plug-ins/extensions to the major browsers (IE, GC, FF, Opera and Safari) which check whether a login page is using SSL? I'm at the Chrome store and so far, I'm not having any luck. A Quest For Knowledge (talk) 14:07, 25 April 2014 (UTC)[reply]

Update: I guess it doesn't have to be a browser add-in/extension. It could be an application or browser setting. I want something to automatically warn me if I'm at a login page not using SSL. A Quest For Knowledge (talk) 14:13, 25 April 2014 (UTC)[reply]

Maybe you're better off without it. Heartbleed. —Nelson Ricardo (talk) 08:04, 26 April 2014 (UTC)[reply]

Not really. On April 17th, 10 days after that bug was announced:

Top 1,000 sites: 0 sites vulnerable (all of them patched)
Top 10,000 sites: 53 sites vulnerable (only 0.53% vulnerable)
Top 100,000 sites: 1595 sites vulnerable (1.5% still vulnerable)
Top 1,000,000 sites: 20320 sites vulnerable (2% still vulnerable)

We're almost 20 days into the problem - I doubt there are many sites that are still vulnerable. So SSL isn't an ongoing problem - and OpenSSL is getting more scrutiny than any piece of software I can ever recall - so it's going to be the best choice going forwards.

To answer the OP's question, I wonder whether you could repurpose any of the MANY heartbleed bug detectors for your cause. After all , if the intended target isn't even running SSL, those tools ought to come up with a suitable error message - and that way, you'll know both whether it uses SSL and whether it's been patched for heartbleed - which is just as important. SteveBaker (talk) 13:48, 26 April 2014 (UTC)[reply]

@Nricardo: Login pages not using SSL is even worse than Heartbleed. If a website's login page isn't using SSL, that means that passwords are being sent as plain text. Anyone who can view Internet traffic can see theses passwords. No hacking is even required. A Quest For Knowledge (talk) 21:18, 26 April 2014 (UTC)[reply]

Not that I'm a particularly expert on web technologies, but as I understand it there is no reason why a page that was transmitted via plain http cannot use a secure channel to do authentication - especially nowadays, where many websites really are Javascript applications, not passive html documents. --Stephan Schulz (talk) 21:41, 26 April 2014 (UTC)[reply]

Yes, websites that switch to HTTPS for logged-in users will normally send credentials over HTTPS even if the login page was served over HTTP, so you're probably safe from passive eavesdropping (e.g. Firesheep). But if any part of the login page is served over HTTP, an active attacker can inject malicious HTML or Javascript that will also send the credentials to the attacker (over HTTPS, even). I think that's what Firebug's warning is for. It's a much more difficult attack, though. -- BenRG (talk) 08:12, 27 April 2014 (UTC)[reply]

@Stephan Schulz: You are correct, it's the post back that needs to be encrypted, not the load of the login page itself. However, there are two problems with that. There's no way to know if the postback is using SSL unless you a) examine the source code or b) examine the HTTP request in Firebug (or some similar tool). Either way requires extra work on my part (which I am doing because I don't know of any simpler way) but I'm looking for a solution that automatically warns me without me having to think about it. Second, the average user doesn't have the technical skills to do either. A Quest For Knowledge (talk) 12:32, 27 April 2014 (UTC)[reply]

@BenRG: You bring up an interesting question (and something that I haven't researched yet). Let's assume that I am on a free WiFi network at Starbucks. If I login to a website that sends my credentials unencrypted (ie. not SSL), doesn't that mean that anyone else on that WiFi network can steal my login credentials? A Quest For Knowledge (talk) 12:38, 27 April 2014 (UTC)[reply]

It depends on whether other people in Starbucks are in promiscuous mode. You might very well think they are; I couldn't possibly comment. Thincat (talk) 12:56, 27 April 2014 (UTC)[reply]

There are alternative encryption mechanisms other than https and transport layer security A secure encryption scheme can be implemented at the application layer, instead of at the transport layer; arguably, this is more secure for certain contexts, because the application developer can assert its integrity even when its local machine's network implementation is untrusted. This can be very important, for example, if secure data is accessed on a shared computer. (i.e., if you want to protect the application data from everybody including the local machine administrator). Think about an Automated Teller Machine - it'd be ludicrous if they used transport layer security only ! Any time a software technician installed the ATM system, he'd be able to set up a root account and eavesdrop on data before it got to the network! This kind of application must implement encryption before the data is readable by local users, let alone network users. Such an application cannot depend on https; https may be used in addition, but arguably adds no additional security.

Let's look at this another way: if you're logging into a web browser and the user-interface crashes (SIGSEGV, or whatever); and a program crash log dumps in-memory contents to a crash report - and securely transmits that crash report to the open-source programmer who gave you your web-browser for free... do you believe that https protects your sensitive data from the programmer who has access to a memory image of your application's runtime state? In that case, sensitive data needs to be encrypted before it reaches the application. Either you need some specialized hardware like a trusted computing module - and a lot of faith in its correct and diligent implementation - and a trusted external service API to encrypt data before providing it to untrusted applications - or you need to do encryption by hand, on paper, before ever entering anything into the application UI. Think long and hard about how to design software for authenticating and authorizing a missile launch! It would be insane to think that a software programmer could be permitted to handle unencrypted data in that context. There is a single boolean bit - "launch now" - that has to be protected from almost everybody - including the programmer who writes code to set that bit - not just malicious network users who learned that WireShark is a thing that exists. HTTPS is entirely superfluous for that scenario.

So when you're staring at a website that, say, authenticates you to your bank, you might need to think really carefully about why https is required. If it is used "for security," and not "for privacy," then your website might not be as secure as it should be. Nimur (talk) 14:10, 27 April 2014 (UTC)[reply]

@Nimur: Oh, I never send crash dumps for precisely the reason you mentioned: I don't want the application developer to be looking at my data. But advantage of using SSL is that the user (if they're using a good browser) can tell whether the website is 'safe' or not. A Quest For Knowledge (talk) 17:57, 28 April 2014 (UTC)[reply]

@A Quest For Knowledge: I don't think it's entirely correct to say that sending in plaintext is worse than Heartbleed. These are different attack vectors. It's true that if you send passwords over plaintext, anyone who gain access to the traffic between you and the server should be able to fairly trivially recover you login details. But how likely this is depends on the connection between you and the server.

E.g. if you are using a public wifi or Tor, there may be at least one obvious weak link which you shouldn't trust. But if you are using a wired connection to your ISP (who you're paying for your connection), you would generally have more trust. Of course, whether a home user ISP or a backbone provider there is a risk they may unwittingly allow someone with malicious purposes access, may be even a member of staff. But it's clearly an attack vector that's difficult for certain attackers, such as script kiddies, to use. (There is a slight risk some packets may end up being sent to the wrong location but I don't believe the risk is very high.)

But with Heartbleed, it's fairly trivial for anyone who is able to access the server, whether a scriptkiddie or whatever, to try and obtain data from the server. The chance they will obtain your password, and in particular, the chance they may be able to automatically process the data they receive to recover it may be slim but there is other stuff, e.g. credit card numbers they may be able to more easily automatically compromise. I think many script kiddies would recognise fooling around with someone's credit card is not a smart move but I expect some would still do so. (I think BenRG also said server private keys although that's something difficult to misuse unless you are able to compromise traffic between the server and you meaning we get back to my earlier point.)

I'm definitely not saying Heartbleed suggest you're better off if a server doesn't use SSL. Simply that Heartbleed leads to largely different attack vectors so it's not so simple as one being worse than the other. Of course most servers were patched before script kiddies had anything they could use but it is an open question whether it's a worse idea to use a server with Heartbleed or a server which doesn't use SSL or any other form of end to end encryption.

Nil Einne (talk) 04:51, 28 April 2014 (UTC)[reply]

The most direct way to see if a form target is SSL in Firefox is to click the right mouse button inside one of the form fields, and choose "inspect element (Q)" from the menu that pops up. That lets you examine the HTML and it will start centered at the form field you selected. Go upwards a few levels in the HTML til you see a form tag, which will say something like <form target=/blabla...>. If the target starts with https: then that is an SSL target. Using SSL widely for stuff like logins on web forums is a fairly new (and good) thing. It used to mostly be used on more sensitive sites like e-commerce (to protect credit card numbers). Wikipedia itself used non-SSL login for a long time, and for a while its SSL site used a CAcert.org certificate that popped browser warnings, so linking to it was kind of an in-group privacy zealot thing. The rise of widespread SSL may be partly due to public wifi networks everywhere routinely getting sniffed or intercepted, partly due to CA monopolies collapsing (you can get $5 or even free certificates now, instead of paying hundreds), and partly due to SSL web servers getting easier to install and configure. 70.36.142.114 (talk) 01:09, 30 April 2014 (UTC)[reply]

SATA connector question

My new computer has four SATA connectors on the motherboard: white (or a very light beige), orange, light blue and dark blue. Of these, the light blue one is connected to the computer's optical drive, and the dark blue one is connected to the hard disk. The white and orange ones are free. Does it matter where I plug the second hard disk in? I intend to install Fedora 20 Linux on it, leaving the existing Windows 8 hard disk absolutely intact. JIP | Talk 15:14, 25 April 2014 (UTC)[reply]

You need to check the motherboard manual for sure. On some chipsets, some of the SATA ports can be used for a RAID, and their ports are typically coloured differently (but if you don't have a RAID configured, these ports just work as normal ports). On newer motherboards, some ports may be SATA2 and some SATA3 (e.g. this one), and again the colours and screenprinting on the circuit board should help identify which is which. And some motherboards contain two SATA controllers (even though these might both be in the same southbridge chip, and again the colours will denote that. I don't know of a standard colour scheme. But mostly you can just plug in anywhere and it'll probably work fine. -- Finlay McWalterᚠTalk 15:26, 25 April 2014 (UTC)[reply]

It will work anywhere, but the hard disks need to be on the fastest ones. Dark blue indicates the faster SATA, so my guess is that the light blue is also fast. My guess is to but the second HD on the light blue SATA connector and move the optical drive to one of the others. Bubba73 ^{You talkin' to me?} 00:37, 26 April 2014 (UTC)[reply]

I'm fairly confused why you say 'dark blue indicates the faster SATA'. Unless I've missed something JIP hasn't indicated what their motherboard is. And I agree with FMW that there probably isn't a standard colour scheme and definitely none has been presented.

I seem to recall an AMD mobo I used where the blue ports were with an extra PCI express chipset which supported the same SATA speed (I think 300) as the mobo chipset SATA (connected via Hyperchannel) which were black so there was no reason why the blue SATA were better and in fact reason to suspect the black could generally be the better choice.

And a quick search finds [3] which shows one mobo which uses different shades of blue, the almost white and dark blue are both SATA 600 and the intermediate blue is SATA 300. Another one is similar but there's it's white rather than an almost white blue (although I don't know if this is just the image quality). Many others similar seem to use white or a very light colour for the Intel SATA 600 (may be Intel recommended this somewhere?). But what they use for the others seems to vary quite a lot, some have black for the additional chipset SATA 600 (where present) and blue for the Intel SATA 300 so clearly always go blue would be rather bad in those cases.

(Although if not for the Intel chipset bug, it may actually be better just to stick with the Intel ones any way if you're talking about a HD like the OP. Since I'm not aware that the chipsets generally provide anything beyond SATA 600 and if you're using a HD without a port doubler or anything it's fairly unlike you'll hit any limit with SATA 300 as current HDs usually can't go much faster than 200 MB/s and I think most SATA 300 ports have no problem achieving close to the limit. Note that things are fairly different for USB where blue indicates USB 3.0 which is part of the standard. And USB 2.0 is fairly slow since even the end of a modern HD will often be able to saturate the theoretical maximum throughput of USB 2.0 let alone the real world of around 35 MB/s [4].)

Nil Einne (talk) 06:48, 28 April 2014 (UTC)[reply]

I was looking at this on one of my computers a month or two ago. It has two 3Gb/sec SATAs and two 6GB/sec SATAs. The faster ones are blue, the slower ones are black. Bubba73 ^{You talkin' to me?} 19:20, 28 April 2014 (UTC)[reply]

OK, there is no consistency from one maker to another, colorwise. Bubba73 ^{You talkin' to me?} 20:14, 28 April 2014 (UTC)[reply]

We need the computer or motherboard model. -- Gadget850^talk 22:42, 28 April 2014 (UTC)[reply]

It's a HP "Elite 7500 Series MT" computer. JIP | Talk 17:57, 29 April 2014 (UTC)[reply]

From the Maintenance & Service Guide from the HP website,

SATA1 dark blue Primary hard drive
SATA2 white Primary optical drive
SATA3 light blue Second hard drive
SATA4 orange Second optical drive Bubba73 ^{You talkin' to me?} 03:27, 30 April 2014 (UTC)[reply]

OK, it looks like I will have to move the cables around. Now I want the computer to dual-boot to either Windows or Linux. I can't modify anything on the existing Windows 8 drive, so I will have to install a dual-boot loader on the new drive. Will the computer be able to boot from it if I don't switch the new drive to the "primary hard drive" slot? JIP | Talk 04:43, 30 April 2014 (UTC)[reply]

Sorry, I don't know anything about dual boot. Bubba73 ^{You talkin' to me?} 04:53, 30 April 2014 (UTC)[reply]

It should be able to - there should be options in the BIOS to specify the boot order, and you can tell it to try to boot to the second disk first. Katie R (talk) 17:11, 30 April 2014 (UTC)[reply]