If he was brilliant he would have made sure that the encrypted stuff he did provide keys for was so wide-spread that it couldn't have been intercepted. Now a few journalists did get it and they were raided, which did provide proof that what he had was the real deal and not fake.
To a lot of people it seems like learning religion dictating the rules of the imaginary "friend" $DIETY is a lot more important than learning useful stuff.
Maybe it's time for organizations to learn that networks need to be segmented within the organization and not put everything on centralized servers. That way it's at least possible to contain any intrusion and malware to a smaller area.
I agree - if you use libraries then provide them with your stuff since otherwise you may suffer from the library getting updated and your package crashing for someone else that uses a library that's too new.
Even if it would make a difference to 10% it would be valuable. Hiding the extension is still extremely stupid, and when it's hidden it's necessary to do additional work to investigate the file to reveal if it is dangerous or not.
And Microsoft has also made this possible by hiding the extension of files in the UIs making it a lot easier for evil people to trick stupid people into clicking on files that they think are images but actually are an executable.
Otherwise I agree that when the systems are down you might be able to pay with cash, however many shops here in Sweden can't even take cash when the systems are down since every transaction has to be securely logged and then sent to the tax authorities. The cash registers used have to be approved by the tax authorities as well.
The point is that this will identify the sending server, and that may allow you to block all servers not identifying themselves, spoofing another server or using revoked certificates.
TLS is just encrypting the channel between servers to prevent sniffers to see the clear text data and possible passwords used to authenticate SMTP sessions.
S/MIME or OpenPGP "only" protects the message itself and provides a way to validate the sender of the message. You may of course configure your server to validate all messages and bounce any S/MIME message that isn't having the correct signature as well as clear text messages. Just be aware that in S/MIME the headers are always in clear text so you may be careful about what you have in the subject line.
Encryption of messages is not prevented by this technology, it's two completely different uses.
- SMTP STS is used for validating the server channel to prevent spoofed servers. It doesn't care about the message content.
- Encrypted messages already exists and encrypts the message body, but that will require that both sender and receiver have exchanged some information. However these messages don't care about the channel used.
For best result you need both.
But I also see problems here:
- the SMTP STS requires certificates provided by a Certificate Authority (CA), and lately it has been revealed that not every CA is especially good at handling this.
- It will also require a good implementation of revocation of certificates.
- The management of the certificates may be costly, both the certificate and the management of it.
Overall it will drive cost, and that may be what kills this idea.
Considering that you can make the locking mechanism a lot sturdier in the computer and less prone to wear the replacement frequency would be magnitudes lower on that compared to how bad it has been with the cables. I have seen countless cables where the only fault have been that darn locking tab broken off. The cost of the time to replace them has been horrible over the years.
Slashdot Mirror
But no president have been good since Ike.
Well, I was more considering negative strategical effect on the security of any country.
It just highlighted the need to take caution.
Like the "Darwin" fish sticker you can purchase.
We are more and more becoming cyborgs, even though today we disconnect us mostly when we enter our beds.
He's good but not brilliant.
If he was brilliant he would have made sure that the encrypted stuff he did provide keys for was so wide-spread that it couldn't have been intercepted. Now a few journalists did get it and they were raided, which did provide proof that what he had was the real deal and not fake.
And what he did reveal was stuff that never made a long term effect anyway. Nobody suffered badly, only some embarrassment to be remembered.
It was enough to make people pay attention, not to get endangered.
In a few years he's just another name on a list of persons wanted but no serious effort would be put into getting him caught.
And guns will soon be about as useful as clubs when the shit goes down the drain because there's a lack of vital parts like gunpowder and firing caps.
The analogy isn't exact, it's like passing by a bad neighborhood on the freeway and risk getting shot at.
To a lot of people it seems like learning religion dictating the rules of the imaginary "friend" $DIETY is a lot more important than learning useful stuff.
Maybe it's time for organizations to learn that networks need to be segmented within the organization and not put everything on centralized servers. That way it's at least possible to contain any intrusion and malware to a smaller area.
Law of Robotics please.
Maybe the bot was victim of a 4chan trolling attack?
I think it was the early ones that had the LC, later they got the full 68040.
My father has a Quadra 610, one of the last true Macs with a Motorola 68k processor.
I agree - if you use libraries then provide them with your stuff since otherwise you may suffer from the library getting updated and your package crashing for someone else that uses a library that's too new.
Even if it would make a difference to 10% it would be valuable. Hiding the extension is still extremely stupid, and when it's hidden it's necessary to do additional work to investigate the file to reveal if it is dangerous or not.
And Microsoft has also made this possible by hiding the extension of files in the UIs making it a lot easier for evil people to trick stupid people into clicking on files that they think are images but actually are an executable.
Even cash has issues with cloning.
Otherwise I agree that when the systems are down you might be able to pay with cash, however many shops here in Sweden can't even take cash when the systems are down since every transaction has to be securely logged and then sent to the tax authorities. The cash registers used have to be approved by the tax authorities as well.
Well, like $15 to $20 for a year or so... Depending on which CA you use.
S/MIME is your answer.
The point is that this will identify the sending server, and that may allow you to block all servers not identifying themselves, spoofing another server or using revoked certificates.
TLS is just encrypting the channel between servers to prevent sniffers to see the clear text data and possible passwords used to authenticate SMTP sessions.
S/MIME or OpenPGP "only" protects the message itself and provides a way to validate the sender of the message. You may of course configure your server to validate all messages and bounce any S/MIME message that isn't having the correct signature as well as clear text messages. Just be aware that in S/MIME the headers are always in clear text so you may be careful about what you have in the subject line.
Like in Thunderbird: "Encrypt this message" when you compose it.
You need to have a mail certificate, but that's no big deal except that you will have to pay for it.
Encryption of messages is not prevented by this technology, it's two completely different uses.
- SMTP STS is used for validating the server channel to prevent spoofed servers. It doesn't care about the message content.
- Encrypted messages already exists and encrypts the message body, but that will require that both sender and receiver have exchanged some information. However these messages don't care about the channel used.
For best result you need both.
But I also see problems here:
- the SMTP STS requires certificates provided by a Certificate Authority (CA), and lately it has been revealed that not every CA is especially good at handling this.
- It will also require a good implementation of revocation of certificates.
- The management of the certificates may be costly, both the certificate and the management of it.
Overall it will drive cost, and that may be what kills this idea.
10 cookies if you can fix that!
Considering that you can make the locking mechanism a lot sturdier in the computer and less prone to wear the replacement frequency would be magnitudes lower on that compared to how bad it has been with the cables. I have seen countless cables where the only fault have been that darn locking tab broken off. The cost of the time to replace them has been horrible over the years.