Try it for yourself. Have someone send you an encrypted email using any random key that you don't have. You'll see the subject line. If you know how to in your mail reader, you can see all of the other headers too.
Even easier, have a look at what's stored for any of your existing email. You'll see the MUA has the email headers amd bodies - it doesn't have the SMTP conversation. That's because MUAs don't receive mail via SMTP.
Guess what else - you can send email via IMAP. Outlook uses MAPI. Protocols that aren't SMTP, yet magically they send encrypted email, without an SMTP envelope. Guess why.
The reason why is that pgp is a mime type like image/jpeg or text/HTML. Look at the source of any of your emails to see where the mime types start.
Microsoft is being misleading by calling it "publicly accessible".
Their "excuse" for saying that may be that the subject is in fact less secured than the email body, by protocol standards. Consider an encrypted email, sent from me to you. Only you and I can read the contents of the email. However, the email has to be handled by various mail servers between us in order to get from me to you. The mail servers need to be ablr to read at least to To: and From: addresses in order to route it, and really some other headers as well. Therefore the email headers can't be encrypted, only the body can be encrypted end-to-end.
Any mail servers between us can see the subject line, and in most cases so can any routers, switches, IDS systems, etc.
In order to be able to troubleshoot problems with emails, compute statistics, etc, headers could also be logged. Typically the log does NOT include the subject line, but it can.
So that wording by Microsoft is a bit deceptive. It is, however, true that if you encrypt your email the subject line and other headers aren't encrypted end-to-end. They can be encrypted per-hop with smtps.
The public switched telephone network isn't any more point-to-point than the internet is. In fact, you know why Ethernet cables have telephone style connectors? Any guess what the "switched network" means in "public switched telephone network?". Think that's anything like the network switch you use for internet? It's precisely the same network, that's why it uses the same connectors and equipment. Some newer companies focus on IP traffic, but all the original backbone ISPs were the traditional phone companies.
A T1 line is a 1.54 Mbps like which typically carries 24 voice channels. It can also carry 1.54 Mbps of data, or a combination of the two. It was originally used just for voice.
Your telephone call / internet traffic does have a point-to-point link from your computer to your switch (which is typically in the same housing as your router). Even inside your home, though, i's a network, many things connect to each other the same switch. Nothing point to point about the phone *network*.
My upstream telephone provider has absolutely no way to know if I've set the caller ID correctly when I forward a call, no more than the next company whom they pass the call to knows.
> Stealth airplanes: Announced and bragged about before deployment.
You've got that backwards. The Lockheed F-117 Nighthawk (stealth fighter) was deployed in 1983. It was Reve publicly in 1988, five years later.
> "Starwars" missile protection: Announced and bragged about before deployment.
Not quite. SDI was mostly bluffing and there was never a design, much less a deployment. It was a concept. At the time the program was shut down, it was estimated it would take another ten years to determine if such a thing were even possible. The US led the Soviet Union to believe we had some kind of proof-of-concept, but there was no such POC, just some ideas of different approaches being tested out.
Those two examples would suggest this rule: Don't tell them about what you have. Tell them all about what you'll never actually have.
We don't know how that happened, unfortunately. We do know the Iraqi air force had Russian-built fighter jets, so they certainly have the ability to shoot an aircraft down. They have have aerial refueling capability, the ability to fly precisely next to another aircraft and give it fuel, or even drop a cargo net on it.
The primary navigation system is inertial guidance, explicitly because spoofing GPS is pretty easy, so GPS spoofing wouldn't be a possibility that would be expected to work.
It *could* have had programming that said basically "if all your sensors are totally confused and you don't know what to do, land". The hobby version I designed and built does that. Then Iran and their allies would have needed to muck with the onboard gyroscopes and other sensors somehow.
What we I do have evidence of is that years later, Lockheed takes security seriously.
I figure management sets the overall tone and priorities, the culture. Management values security.
Their people have the ability and interest to deliver security.
So there is a pretty good chance that they do a good job. Lockheed isn't a customer of ours, so I haven't done a security audit of them. I do have enough information to make an educated prediction or hypothesis.
Of course that's relative to other companies. We do have banks as customers, so I know how bad / good some banks are regarding security. Overall, the software industry sucks at security and reliability. We need about four times as many *engineers* in the roles that have job titles like "senior software engineer". Engineering means designing things to meet known requirements based on proven design methods. Software is often built with little or no engineering involved.
It's written as Emacs and systemd modules. Nothing to worry about here!
In all seriousness, I was actually thinking of a different security contractor in town when I posted that. Lockheed asks F-35 candidates to know some of the following:
With Glassdoor you can see them hiring a lot of experienced security professionals, and see what the pay is, along with the qualifications they expect of everyone working on the system.
That's all from ONE open source intelligence resource, which anyone can see in less than 20 minutes.
If you happen to be a 20-year career veteran in the security space, working 25 minutes Lockheed headquarters and hanging out with their engineers at ISC2 meetings every month, you can really get to know their security culture if you're paying attention.
You can then easily position yourself, over the next 12 months, to have exactly the knowledge and references they'd like to see in a new hire, giving you an excellent backup plan whenever you decide to quit your job at $major_security_company.
I shouldn't have said "special sauce". It's the Big Mac that had "special sauce". The quarter pounder has mustard and ketchup.
Special sauce (Mac sauce) is similar to Thousand Island, except special sauce doesn't have tomatoes or ketchup. Special sauce is: sweet pickle relish, mayo, vinegar, mustard, garlic powder, onion powder, and paprika.
The recipe for a McDonald's Quarter Pounder with Cheese is:
quarter pound of beef Cheese mustard and ketchup ("special sauce") onion pickles
That's either true or false. The recipe itself, the list of ingredients and their amounts, are facts. There is no copy right on facts.
In a well-known commercial, the ingredients are sung in a certain order to a certain tune. That presentation of the recipe is an artistic expression rather than a fact. There is a copyright on that.
If a recipe book has a paragraph describing the food or the cooking process in prose, that prose description may be copyright eligible. The factual list of which ingredients are used is not protectable.
If the data is actually worth hundreds of thousands of dollars, or tens of thousands, do you think having a backup might be a good idea? Or should you run recovery tools on your only copy, in a system that apparently has bugs software that randomly deletes stuff or a dodgy drive controller or whatever caused the problem, while you're under stress and the adrenaline and high heart rate has cut your cerebral cortex function by 40%?
You should have put another copy in the other room LAST MONTH. Do it now.
If there is nothing interesting about your storage, yes testdisk is great. It should be used on an image of the media, preferably a read-only image. Do NOT try to recover from the original media, if it's valuable to you. The only thing you should do with the original media is make an image of it, then unplug it and move it to a different room.
If you're using raid, volumes, or other more interesting storage recovery is still possible in most cases, but it gets more complicated. There are a lot of ways to go wrong.
If you've deleted data that is worth $250,000, it's foolish to touch it at all if you don't have both experience doing data recovery and knowledge of the on-disk format at each level - partitions, volume manager, raid, filesystem, etc. If it's worth $250,000, it's worth spending $1,000 to have it recovered by someone who knows what they are doing.
If you find yourself needing to recover data that's worth tens of thousands of dollars or more, you can contact me. When *I* want some help, I talk to Neil Brown and Ted T'so.
Yep, that's what you get when you take a 1970s protocol and try to duct tape security on it. With modern protocols, you just establish a secure connection in the first place. No need to establish an insecure one first, then start talking about switching over to a secure one.
> One can't get a postcard from an unknown address using unknown cypher and understand the message.
And sending back and forth postcards saying "may I send you a postcard?", "Yes you may send me a postcard", "Okay I'll send you a postcard soon" doesn't help with that.
Here's a quick outline of each, TLS duct-taped to TCP, vs QUIC:
TLS on top of TCP: C: hello I'm 1.2.3.4 and I'd like to talk to port 443 S: Okay, you can talk to port 443 if you really want to C: Yes, I really want to talk to port 443 C: Can we use ECC encryption? S: yes we can use ECC C: Okay let's use ECC S: Cool, ECC it is
QUIC: C: hello I'm 1.2.3.4 and I'd like to talk to port 443 using ECC S: You are now talking to port 443 using ECC
The difference being that other sites don't KNOW when their traffic is being routed through Russia. Google knows, and with certificate pinning and other safeguards, the site just ends up being down rather than having surveillance actually work like it does for other sites.
TLS on top of TCP: C: hello I'm 1.2.3.4 and I'd like to talk to port 443 S: Okay, you can talk to port 443 if you really want to C: Yes, I really want to talk to port 443 C: Can we use ECC encryption? S: yes we can use ECC C: Okay let's use ECC S: Cool, ECC it is
QUIC: C: hello I'm 1.2.3.4 and I'd like to talk to port 443 using ECC S: You are now talking to port 443 using ECC
> you think DDOS is going to obey any of the rules? that's so naive > It just makes a connection, first stage , not a full connections, this is enough to tie up resources on the server
That's true of TCP, you can DOS with a syn flood. Since that's a big problem, people duct-taped on a workaround called syn cookies. Since TCP wasn't designed to use sun cookies, they cause other problems. Notably it hurts performance because the syn cookie doesn't leave room for important TCP options. Things like selective ACKs and TCP Window Scaling won't work if you turn on SYN Cookies, even if your server isn't currently under attack.
QUIC, on the other hand, has stateless sessions similar in concept to syn cookies designed in, so everything works. You don't have to give up anything to avoid DOS with QUIC since it was designed with that protection in mind.
Application layer protocols such as http operate on top of the transport layer. Application layer can be on top of TCP, because TCP is transport layer. Application layer like HTTP can also be on top of TLS, Transport Layer Security, because Transport Layer Security is - transport layer.
There is no "security layer" in either the OSI model or the TCP/IP model. Please review chapter 2 of Networking for Dummies.
You could take five minutes to get a very basic idea of how QUIC works before you dismiss it. There is a connection, very similar most VPN connections.
Originally HTTP ran over plaintext, unencrypted TCP. There was a TCP session. Then there was the option to tunnel an SSL session over the TCP connection, so you had a session within a session. You'd first establish a TCP connection, doing the whole handshake dance, then start the handshake dance over again for SSL. That's just as slow and inefficient as it sounds.
Now that we're moving to TLS on all web connections, setting up a TCP session just to then set up a TLS connection is wasteful and silly. Many protocols designed for encrypted connections, such as ipsec and openvpn, work better by just setting up the connection once. They just do one handshake, which sets up the encrypted connection, over UDP.
That's what QUIC does - the handshake sets up an encrypted TLS connection, over UDP. That's faster and more efficient. That's why openvpn, ipsec, quic, and most protocols originally designed for encrypted connections skip setting up two sessions, an unencrypted TCP session and then an encrypted session riding it. Just set up one encrypted session.
See for example Campbell v. Acuff-Rose Music, 510 U.S. 569 (1994) regarding transformative fair use. Also many earlier rulings. http://www.law.cornell.edu/sup...
There is a big difference between criticism and parody in fair use law. One can criticize something without copying it. Parody by it's very nature requires the characteristic elements of the work. Therefore, a criticism does not necessarily have a fair reason to copy; a parody does because the parody cannot exist without copying.
> Too long to be fair use, and it's the centre point of the music anyway.
You're thinking of one type fair use. If you're writing a research paper, you can use a short section from another research paper. "A short section" is only ONE of several types of fair use though.
Two other fair use elements are "transformative" and, most importantly, market for the original work. If you made a rave song, using sampled audio from a newscast, that's probably okay because it's completely transformative. You can use the ENTIRE original work and it can still be fair use. See Kelly vs Arriba and other cases.
Another element, probably the most important, is the effect of your use on the market value of the original work. Will people buy your song INSTEAD OF buying the TV show? If not, that has two effects: It makes it probably fair use. It means actual damages* would be $0 anyway, so it doesn't *matter* if it's infringing.
If your song parodies or comments on the show, if it says something about contemporary culture as exemplified by the show, that may be fair use.
There are many factors to consider for fair use. If the show was a stand-up comedy skit and you used most of it to make a comedy song, that would probably infringe. I'd bet that you're aong is transformative enough that it doesn't compete with the prior work or damage its market value, though.
* Statutory damages are a thing. I won't go into that here.
Slashdot Mirror
Try it for yourself. Have someone send you an encrypted email using any random key that you don't have. You'll see the subject line. If you know how to in your mail reader, you can see all of the other headers too.
Even easier, have a look at what's stored for any of your existing email. You'll see the MUA has the email headers amd bodies - it doesn't have the SMTP conversation. That's because MUAs don't receive mail via SMTP.
Guess what else - you can send email via IMAP. Outlook uses MAPI. Protocols that aren't SMTP, yet magically they send encrypted email, without an SMTP envelope. Guess why.
The reason why is that pgp is a mime type like image/jpeg or text/HTML. Look at the source of any of your emails to see where the mime types start.
Microsoft is being misleading by calling it "publicly accessible".
Their "excuse" for saying that may be that the subject is in fact less secured than the email body, by protocol standards. Consider an encrypted email, sent from me to you. Only you and I can read the contents of the email. However, the email has to be handled by various mail servers between us in order to get from me to you. The mail servers need to be ablr to read at least to To: and From: addresses in order to route it, and really some other headers as well. Therefore the email headers can't be encrypted, only the body can be encrypted end-to-end.
Any mail servers between us can see the subject line, and in most cases so can any routers, switches, IDS systems, etc.
In order to be able to troubleshoot problems with emails, compute statistics, etc, headers could also be logged. Typically the log does NOT include the subject line, but it can.
So that wording by Microsoft is a bit deceptive. It is, however, true that if you encrypt your email the subject line and other headers aren't encrypted end-to-end. They can be encrypted per-hop with smtps.
The public switched telephone network isn't any more point-to-point than the internet is. In fact, you know why Ethernet cables have telephone style connectors? Any guess what the "switched network" means in "public switched telephone network?". Think that's anything like the network switch you use for internet? It's precisely the same network, that's why it uses the same connectors and equipment. Some newer companies focus on IP traffic, but all the original backbone ISPs were the traditional phone companies.
A T1 line is a 1.54 Mbps like which typically carries 24 voice channels. It can also carry 1.54 Mbps of data, or a combination of the two. It was originally used just for voice.
Your telephone call / internet traffic does have a point-to-point link from your computer to your switch (which is typically in the same housing as your router). Even inside your home, though, i's a network, many things connect to each other the same switch. Nothing point to point about the phone *network*.
My upstream telephone provider has absolutely no way to know if I've set the caller ID correctly when I forward a call, no more than the next company whom they pass the call to knows.
> Stealth airplanes: Announced and bragged about before deployment.
You've got that backwards. The Lockheed F-117 Nighthawk (stealth fighter) was deployed in 1983. It was Reve publicly in 1988, five years later.
> "Starwars" missile protection: Announced and bragged about before deployment.
Not quite. SDI was mostly bluffing and there was never a design, much less a deployment. It was a concept. At the time the program was shut down, it was estimated it would take another ten years to determine if such a thing were even possible. The US led the Soviet Union to believe we had some kind of proof-of-concept, but there was no such POC, just some ideas of different approaches being tested out.
Those two examples would suggest this rule:
Don't tell them about what you have.
Tell them all about what you'll never actually have.
We don't know how that happened, unfortunately. We do know the Iraqi air force had Russian-built fighter jets, so they certainly have the ability to shoot an aircraft down. They have have aerial refueling capability, the ability to fly precisely next to another aircraft and give it fuel, or even drop a cargo net on it.
The primary navigation system is inertial guidance, explicitly because spoofing GPS is pretty easy, so GPS spoofing wouldn't be a possibility that would be expected to work.
It *could* have had programming that said basically "if all your sensors are totally confused and you don't know what to do, land". The hobby version I designed and built does that. Then Iran and their allies would have needed to muck with the onboard gyroscopes and other sensors somehow.
What we I do have evidence of is that years later, Lockheed takes security seriously.
I figure management sets the overall tone and priorities, the culture. Management values security.
Their people have the ability and interest to deliver security.
So there is a pretty good chance that they do a good job. Lockheed isn't a customer of ours, so I haven't done a security audit of them. I do have enough information to make an educated prediction or hypothesis.
Of course that's relative to other companies. We do have banks as customers, so I know how bad / good some banks are regarding security. Overall, the software industry sucks at security and reliability. We need about four times as many *engineers* in the roles that have job titles like "senior software engineer". Engineering means designing things to meet known requirements based on proven design methods. Software is often built with little or no engineering involved.
It's written as Emacs and systemd modules. Nothing to worry about here!
In all seriousness, I was actually thinking of a different security contractor in town when I posted that. Lockheed asks F-35 candidates to know some of the following:
Go
Python
Java
Assembly
C / C++
The original post was actually somewhat correct.
With Glassdoor you can see them hiring a lot of experienced security professionals, and see what the pay is, along with the qualifications they expect of everyone working on the system.
That's all from ONE open source intelligence resource, which anyone can see in less than 20 minutes.
If you happen to be a 20-year career veteran in the security space, working 25 minutes Lockheed headquarters and hanging out with their engineers at ISC2 meetings every month, you can really get to know their security culture if you're paying attention.
You can then easily position yourself, over the next 12 months, to have exactly the knowledge and references they'd like to see in a new hire, giving you an excellent backup plan whenever you decide to quit your job at $major_security_company.
Lockheed takes the security of this system, and all of their weapons systems, pretty darn seriously.
Neither of those. Care to try again?
Those are funny
I shouldn't have said "special sauce". It's the Big Mac that had "special sauce". The quarter pounder has mustard and ketchup.
Special sauce (Mac sauce) is similar to Thousand Island, except special sauce doesn't have tomatoes or ketchup. Special sauce is:
sweet pickle relish, mayo, vinegar, mustard, garlic powder, onion powder, and paprika.
The recipe for a McDonald's Quarter Pounder with Cheese is:
quarter pound of beef
Cheese
mustard and ketchup ("special sauce")
onion
pickles
That's either true or false. The recipe itself, the list of ingredients and their amounts, are facts. There is no copy right on facts.
In a well-known commercial, the ingredients are sung in a certain order to a certain tune. That presentation of the recipe is an artistic expression rather than a fact. There is a copyright on that.
If a recipe book has a paragraph describing the food or the cooking process in prose, that prose description may be copyright eligible. The factual list of which ingredients are used is not protectable.
If the data is actually worth hundreds of thousands of dollars, or tens of thousands, do you think having a backup might be a good idea? Or should you run recovery tools on your only copy, in a system that apparently has bugs software that randomly deletes stuff or a dodgy drive controller or whatever caused the problem, while you're under stress and the adrenaline and high heart rate has cut your cerebral cortex function by 40%?
You should have put another copy in the other room LAST MONTH. Do it now.
If there is nothing interesting about your storage, yes testdisk is great. It should be used on an image of the media, preferably a read-only image. Do NOT try to recover from the original media, if it's valuable to you. The only thing you should do with the original media is make an image of it, then unplug it and move it to a different room.
If you're using raid, volumes, or other more interesting storage recovery is still possible in most cases, but it gets more complicated. There are a lot of ways to go wrong.
If you've deleted data that is worth $250,000, it's foolish to touch it at all if you don't have both experience doing data recovery and knowledge of the on-disk format at each level - partitions, volume manager, raid, filesystem, etc. If it's worth $250,000, it's worth spending $1,000 to have it recovered by someone who knows what they are doing.
If you find yourself needing to recover data that's worth tens of thousands of dollars or more, you can contact me. When *I* want some help, I talk to Neil Brown and Ted T'so.
I work in the field too. Cataloged 80 new vulnerabilities today.
NlGGER is a horrible word.
> The connection comes first, then the security.
Yep, that's what you get when you take a 1970s protocol and try to duct tape security on it. With modern protocols, you just establish a secure connection in the first place. No need to establish an insecure one first, then start talking about switching over to a secure one.
> One can't get a postcard from an unknown address using unknown cypher and understand the message.
And sending back and forth postcards saying "may I send you a postcard?", "Yes you may send me a postcard", "Okay I'll send you a postcard soon" doesn't help with that.
Here's a quick outline of each, TLS duct-taped to TCP, vs QUIC:
TLS on top of TCP:
C: hello I'm 1.2.3.4 and I'd like to talk to port 443
S: Okay, you can talk to port 443 if you really want to
C: Yes, I really want to talk to port 443
C: Can we use ECC encryption?
S: yes we can use ECC
C: Okay let's use ECC
S: Cool, ECC it is
QUIC:
C: hello I'm 1.2.3.4 and I'd like to talk to port 443 using ECC
S: You are now talking to port 443 using ECC
The difference being that other sites don't KNOW when their traffic is being routed through Russia. Google knows, and with certificate pinning and other safeguards, the site just ends up being down rather than having surveillance actually work like it does for other sites.
TLS on top of TCP:
C: hello I'm 1.2.3.4 and I'd like to talk to port 443
S: Okay, you can talk to port 443 if you really want to
C: Yes, I really want to talk to port 443
C: Can we use ECC encryption?
S: yes we can use ECC
C: Okay let's use ECC
S: Cool, ECC it is
QUIC:
C: hello I'm 1.2.3.4 and I'd like to talk to port 443 using ECC
S: You are now talking to port 443 using ECC
> you think DDOS is going to obey any of the rules? that's so naive
> It just makes a connection, first stage , not a full connections, this is enough to tie up resources on the server
That's true of TCP, you can DOS with a syn flood.
Since that's a big problem, people duct-taped on a workaround called syn cookies. Since TCP wasn't designed to use sun cookies, they cause other problems. Notably it hurts performance because the syn cookie doesn't leave room for important TCP options. Things like selective ACKs and TCP Window Scaling won't work if you turn on SYN Cookies, even if your server isn't currently under attack.
QUIC, on the other hand, has stateless sessions similar in concept to syn cookies designed in, so everything works. You don't have to give up anything to avoid DOS with QUIC since it was designed with that protection in mind.
Application layer protocols such as http operate on top of the transport layer. Application layer can be on top of TCP, because TCP is transport layer. Application layer like HTTP can also be on top of TLS, Transport Layer Security, because Transport Layer Security is - transport layer.
There is no "security layer" in either the OSI model or the TCP/IP model. Please review chapter 2 of Networking for Dummies.
You could take five minutes to get a very basic idea of how QUIC works before you dismiss it. There is a connection, very similar most VPN connections.
Originally HTTP ran over plaintext, unencrypted TCP. There was a TCP session.
Then there was the option to tunnel an SSL session over the TCP connection, so you had a session within a session. You'd first establish a TCP connection, doing the whole handshake dance, then start the handshake dance over again for SSL. That's just as slow and inefficient as it sounds.
Now that we're moving to TLS on all web connections, setting up a TCP session just to then set up a TLS connection is wasteful and silly. Many protocols designed for encrypted connections, such as ipsec and openvpn, work better by just setting up the connection once. They just do one handshake, which sets up the encrypted connection, over UDP.
That's what QUIC does - the handshake sets up an encrypted TLS connection, over UDP. That's faster and more efficient. That's why openvpn, ipsec, quic, and most protocols originally designed for encrypted connections skip setting up two sessions, an unencrypted TCP session and then an encrypted session riding it. Just set up one encrypted session.
See for example Campbell v. Acuff-Rose Music, 510 U.S. 569 (1994) regarding transformative fair use. Also many earlier rulings.
http://www.law.cornell.edu/sup...
There is a big difference between criticism and parody in fair use law. One can criticize something without copying it. Parody by it's very nature requires the characteristic elements of the work. Therefore, a criticism does not necessarily have a fair reason to copy; a parody does because the parody cannot exist without copying.
> Too long to be fair use, and it's the centre point of the music anyway.
You're thinking of one type fair use. If you're writing a research paper, you can use a short section from another research paper. "A short section" is only ONE of several types of fair use though.
Two other fair use elements are "transformative" and, most importantly, market for the original work. If you made a rave song, using sampled audio from a newscast, that's probably okay because it's completely transformative. You can use the ENTIRE original work and it can still be fair use. See Kelly vs Arriba and other cases.
Another element, probably the most important, is the effect of your use on the market value of the original work. Will people buy your song INSTEAD OF buying the TV show? If not, that has two effects:
It makes it probably fair use.
It means actual damages* would be $0 anyway, so it doesn't *matter* if it's infringing.
If your song parodies or comments on the show, if it says something about contemporary culture as exemplified by the show, that may be fair use.
There are many factors to consider for fair use. If the show was a stand-up comedy skit and you used most of it to make a comedy song, that would probably infringe. I'd bet that you're aong is transformative enough that it doesn't compete with the prior work or damage its market value, though.
* Statutory damages are a thing. I won't go into that here.