>The owner of spi.dod.mil has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
Same here in Chromium. Typical... The actual problem seems to be with the cert chain.
The whole site is a joke, but then again, so are most US govt sites. I don't understand why they have to keep using ugly, outdated and badly operating websites over there.
Because they work? Especially if you are Joe Public who has been trained for years to just click past any warnings on any website. Because most people feel their tax dollars are better spent on things other than redesigning government websites because they "look old?"
> Because most people feel their tax dollars are better spent on things other than redesigning government websites because they "look old?"
The beauty of Twitter Bootstrap is that good get a modern responsive website with less work than rolling your own design, or even having to think about it.
What's the problem? Sounds like a good idea. If they ever abuse their status they get revoked, causing them a lot of pain. More pain than if they hadn't been depending on being trusted in the first place.
Revoking CA's is considerably harder than you think it might work for you but it might not work for the tons of people that do not update their browsers or operating systems.
Private/Internal/Enterprise CA's are intentionally out of the ring of trust for SSL certificates, there is no need to give the DoD any preferential treatment.
This would literally benefit no one as anyone with any interest in accessing those websites would install the certificate.
US .gov sites are "secured" with commercial CA certificates so they aren't even part of the argument.
When you count the benefit / usefulness of this change which is very little to null and compare it to the possibility of it being abused as well as the precedent of adding "internal" certificate authorities to the global trust list I see a pretty solid argument against this.
Overall with things like LetsEncrypt I hope that the CA/SSL Cert industry would get disrupted enough for most if not all commercial CA's to simply become irrelevant.
It's not a question of insurance rather than a technical issue since you still get an 'n' figures "fraud" insurance when you purchase validated SSL certificates from commercial CA's and some standards require you to use them rather than LE and the likes.
To my knowledge I do not know of any case on which that insurance has ever been successfully claimed so this entire premise should be just killed off completely.
'LE' and similar services should then be managed by a non-profit or a handful of those maybe for each region and just be done with it, the CA list is already too big and it's already near impossible to figure out who owns what besides the <10 big players.
I honestly see no reason for SSL to work a browser have to have a list of 130-150 CA's on file (default Root+Intermediate CA listing on Windows).
And by lots of other CAs, too. I've never seen a cert that has such a long chain (up to 10 intermediates), not to mention, multiple long chains. This probably would be trusted by most browsers (path 7), but one intermediate expired last month.
There are (impressively thorough, including recommendations on out-of-band fingerprint authentication) installation instructions included, and they provide PEM, PKCS7, and some weirdo Windows format.
However, _that_ website is not served over HTTPS, which would seem to make it a prime target of MITM. Do you happen to have an HTTPS link to obtain these certs?
I haven't found one, but I suspect the IASE page is only over HTTP for legacy reasons, as there are lots of things that download stuff automatically from DISA. I could be wrong though, and I agree that it should be served over HTTPS. The main DISA page is served over HTTPS: https://www.disa.mil
> there are lots of things that download stuff automatically from DISA
So, programs are downloading certs automatically, where they would be even less likely to properly check checksums against a secure site. And create a additional small attack vector.
> I haven't found one, but I suspect the IASE page is only over HTTP for legacy reasons
Well, also because an HTTPS page would create a chicken-and-egg situation. How do you download the root certs if you can't see the page because you don't have the root certs? etc
I have the DoD root certs installed, my browser still isn't happy. It doesn't instill a lot of confidence in their encryption software when the website hawking it is still using SHA-1.
We have almost zero control over the webserver; it's run by a completely separate group of people. We can change some of the content, but next to nothing of the server config itself.
(I realize that may sound strange to those of you who have never worked with any DoD organizations. Imagine going to one of the largest bureaucracies on the planet and saying, "We want you to change something.")
So yeah, none of us are happy about the current situation. Trying to distribute security-oriented software via a website with a SHA-1 cert signed by a root cert that has to be installed separately... the irony is nearly poetic.
Hoping to move to a completely different web host (still DoD, just different) before the end of the year. Most of us would be like, "we could do that in a day, plus DNS TTL expirations," but when they're not actually in combat, the DoD moves at... well, they move at the speed of government! :-)
Looks like they've since replaced it with a SHA256 cert. It was issued on the 22nd, so apparently they were already in the process of fixing it when this was posted to HN.
can we stop being lame and complaining about https certs of something you're not downloading binaries or submitting information? just consider it http and move on. sigh.
Nope. The more traffic that is encrypted the better. Protects privacy, ensures you're connecting to the right source, and helps prevent ISPs from throttling/caching based on the content.
I got curious and opened this project in JD-GUI. The namespace is afrlew, which I presume is some sort of acronym.
EDIT: Of course it is! AFRLEW = Air Force Research Laboratory Encryption Wizard
The lion's share of the crypto appears to be in called Hut8.class, which JD-GUI didn't fully decode successfully.
This looks odd:
private void incrementSaltIndex(byte[] paramArrayOfByte, int paramInt)
{
int tmp5_4 = (paramInt + 3);
paramArrayOfByte;
if (0 == (tmp5_1[tmp5_4] = (byte)(tmp5_1[tmp5_4] + 1)))
{
int tmp20_19 = (paramInt + 2);
paramArrayOfByte;
if (0 == (tmp20_16[tmp20_19] = (byte)(tmp20_16[tmp20_19] + 1)))
{
int tmp35_34 = (paramInt + 1);
paramArrayOfByte;
if (0 == (tmp35_31[tmp35_34] = (byte)(tmp35_31[tmp35_34] + 1)))
{
int tmp50_49 = (paramInt + 0);
paramArrayOfByte;
if (0 == (tmp50_46[tmp50_49] = (byte)(tmp50_46[tmp50_49] + 1))) {
throw new ArithmeticException("Value overflow");
}
}
}
}
}
Their PasswordGenerator class is also interesting. Has a loop that runs for an arbitrary 80000 iterations, etc.
Overall, no obvious vulnerabilities, but definitely in the "written by a bored undergrad student in their spare time" realm from what I saw. Obviously, I wouldn't recommend using it.
Hi! Current software maintainer here. (I meant to reply earlier, and then a storm knocked out power to my house.)
The weird routine you posted is for backwards compat reasons only. It's used solely when decrypting our very first file format, which we care about only because some people never throw anything away. Obviously the password stretching has to match exactly, so the code that originally stretched it (PBKDF 1.5) is still there. It's not been used for new files in the last... five years? Since before my predecessor, anyway.
Encrypting/decrypting with a password these days uses standard PBKDF 2.0, with a configurable-as-long-as-its-larger iteration count. Been poking at other stretching schemes too, but none of them are included in released versions yet.
At some point we'll drop support for decrypting the early versions and get rid of all that cruft. Anybody still needing their ancient files can use an earlier release.
> Their PasswordGenerator class is also interesting. Has
> a loop that runs for an arbitrary 80000 iterations, etc.
The generator doesn't need to loop at all. The first implementation did, because hysterical raisins. The current random generator just does its work in a single pass. Cleaning up the surrounding code (including that needless loop structure) is on the todo list, but not a priority for the end customer.
Interesting! I never imagined someone from DoD would respond to my quick analysis.
In all fairness, JD-GUI wasn't exactly great at reversing the class file to Java code and missed quite a bit. I haven't had a chance to analyze it further.
Is there any chance the DoD could open source this application (e.g. on Github, or some other site)?
FWIW, a few bits of the Java source are generated from other languages. So if JD-GUI produces something that looks just freaky bizarre, the answer might well be that the actual Java source really does look like that, but that's not what "the original" file is written in, if that makes sense. Like 95% of the project is maintained in straight up Java, but things dealing with different crypto implementations, or features not available in the public release, are sometimes maintained "one level up".
Full disclosure: I'm a contractor, not a DoD employee; as the maintainer I can safely speak for what the project was and is. But as to what the project will do in the future, all I can do is give you my best Magic Eight Ball guess. Namely: if it happens, it probably won't be soon. Most of us on the project are big believers in open source but convincing the higher-ups that it would be worth doing that for EW is a looooooooong undertaking.
Going open source -- or making any other change to policy, or management, or whatever -- has to help the DoD solve the problems which this software was created to solve. It's not that the entire organization is against the idea of libre software -- AFRL is a research group, they get how good software development works -- it's just that their default position is "make no change" and any other approach has to show a demonstrable, concrete benefit over what they're already getting.
In the meantime... well, the EW-Public license specifically allows decompiling, which everybody was going to do anyhow. :-) It's not the same, but it makes looking for vulnerabilities way easier.
I wouldn't use this if you're not dealing with the DoD. However, if you're in the DoD trying to work with an external collaborator, services like this provide at least some way to show, for example, an IRB, that you're moving PHI with due diligence.
45 comments
[ 2.7 ms ] story [ 87.5 ms ] threadoh, yeah, totally clicking on that.
The whole site is a joke, but then again, so are most US govt sites. I don't understand why they have to keep using ugly, outdated and badly operating websites over there.
The beauty of Twitter Bootstrap is that good get a modern responsive website with less work than rolling your own design, or even having to think about it.
DoD today, UK MOD tomorrow, Russia and China when?
Private/Internal/Enterprise CA's are intentionally out of the ring of trust for SSL certificates, there is no need to give the DoD any preferential treatment.
This would literally benefit no one as anyone with any interest in accessing those websites would install the certificate.
US .gov sites are "secured" with commercial CA certificates so they aren't even part of the argument.
When you count the benefit / usefulness of this change which is very little to null and compare it to the possibility of it being abused as well as the precedent of adding "internal" certificate authorities to the global trust list I see a pretty solid argument against this.
Overall with things like LetsEncrypt I hope that the CA/SSL Cert industry would get disrupted enough for most if not all commercial CA's to simply become irrelevant.
It's not a question of insurance rather than a technical issue since you still get an 'n' figures "fraud" insurance when you purchase validated SSL certificates from commercial CA's and some standards require you to use them rather than LE and the likes.
To my knowledge I do not know of any case on which that insurance has ever been successfully claimed so this entire premise should be just killed off completely.
'LE' and similar services should then be managed by a non-profit or a handful of those maybe for each region and just be done with it, the CA list is already too big and it's already near impossible to figure out who owns what besides the <10 big players.
I honestly see no reason for SSL to work a browser have to have a list of 130-150 CA's on file (default Root+Intermediate CA listing on Windows).
https://www.ssllabs.com/ssltest/analyze.html?d=spi.dod.mil&s...
http://iase.disa.mil/pki-pke/Documents/unclass-installroot_v...
There are (impressively thorough, including recommendations on out-of-band fingerprint authentication) installation instructions included, and they provide PEM, PKCS7, and some weirdo Windows format.
Alternatively, the DoD certs served up securely by Symantec: https://knowledge.symantec.com/support/eca-support/index?pag...
So, programs are downloading certs automatically, where they would be even less likely to properly check checksums against a secure site. And create a additional small attack vector.
Well, also because an HTTPS page would create a chicken-and-egg situation. How do you download the root certs if you can't see the page because you don't have the root certs? etc
We have almost zero control over the webserver; it's run by a completely separate group of people. We can change some of the content, but next to nothing of the server config itself.
(I realize that may sound strange to those of you who have never worked with any DoD organizations. Imagine going to one of the largest bureaucracies on the planet and saying, "We want you to change something.")
So yeah, none of us are happy about the current situation. Trying to distribute security-oriented software via a website with a SHA-1 cert signed by a root cert that has to be installed separately... the irony is nearly poetic.
Hoping to move to a completely different web host (still DoD, just different) before the end of the year. Most of us would be like, "we could do that in a day, plus DNS TTL expirations," but when they're not actually in combat, the DoD moves at... well, they move at the speed of government! :-)
This is a post about encryption, a site and program for encryption.
It also has file hashes and downloads (zips) on it; so, that meets some of your qualifications.
EDIT: Of course it is! AFRLEW = Air Force Research Laboratory Encryption Wizard
The lion's share of the crypto appears to be in called Hut8.class, which JD-GUI didn't fully decode successfully.
This looks odd:
Their PasswordGenerator class is also interesting. Has a loop that runs for an arbitrary 80000 iterations, etc.Overall, no obvious vulnerabilities, but definitely in the "written by a bored undergrad student in their spare time" realm from what I saw. Obviously, I wouldn't recommend using it.
The weird routine you posted is for backwards compat reasons only. It's used solely when decrypting our very first file format, which we care about only because some people never throw anything away. Obviously the password stretching has to match exactly, so the code that originally stretched it (PBKDF 1.5) is still there. It's not been used for new files in the last... five years? Since before my predecessor, anyway.
Encrypting/decrypting with a password these days uses standard PBKDF 2.0, with a configurable-as-long-as-its-larger iteration count. Been poking at other stretching schemes too, but none of them are included in released versions yet.
At some point we'll drop support for decrypting the early versions and get rid of all that cruft. Anybody still needing their ancient files can use an earlier release.
> Their PasswordGenerator class is also interesting. Has > a loop that runs for an arbitrary 80000 iterations, etc.
The generator doesn't need to loop at all. The first implementation did, because hysterical raisins. The current random generator just does its work in a single pass. Cleaning up the surrounding code (including that needless loop structure) is on the todo list, but not a priority for the end customer.
Cheers!
In all fairness, JD-GUI wasn't exactly great at reversing the class file to Java code and missed quite a bit. I haven't had a chance to analyze it further.
Is there any chance the DoD could open source this application (e.g. on Github, or some other site)?
Full disclosure: I'm a contractor, not a DoD employee; as the maintainer I can safely speak for what the project was and is. But as to what the project will do in the future, all I can do is give you my best Magic Eight Ball guess. Namely: if it happens, it probably won't be soon. Most of us on the project are big believers in open source but convincing the higher-ups that it would be worth doing that for EW is a looooooooong undertaking.
Going open source -- or making any other change to policy, or management, or whatever -- has to help the DoD solve the problems which this software was created to solve. It's not that the entire organization is against the idea of libre software -- AFRL is a research group, they get how good software development works -- it's just that their default position is "make no change" and any other approach has to show a demonstrable, concrete benefit over what they're already getting.
In the meantime... well, the EW-Public license specifically allows decompiling, which everybody was going to do anyhow. :-) It's not the same, but it makes looking for vulnerabilities way easier.
Not that it means anything, but NIPRNet is the unclassified network, SIPRNET is secret level.
So this is not accredited to run on Top Secret and above.
Unendorsed polyseme: Encryption Wizard for Oracle [http://www.relationalwizards.com/]
uh... How can I say this... :)
wut?
If you're willing to click past the website (DoD root certificates explained elsewhere), you could read more on the FAQ: https://www.spi.dod.mil/ewizardFAQ.htm#FAQkp.3
The difference between the two is that one has FIPS 140-2 paperwork and the other does not.
The DoD maintains a PKI system that is essentially independent of the rest of the world's crypto: http://iase.disa.mil/pki-pke/interoperability/Pages/index.as...