If your car is worth anything at all, odds are someone will desire to take it. I've seen videos of people stealing various makes of BMW via diag hacks, made easier by alarm blind spots. And it's not limited to high-ish end makes; bog-standard hondas, vws, and fords are stolen and stripped all the time.
It gets much easier with "OnStar"... that's a radio with complete control of the car.
The ability to access your server may be limited -- and the more it's used, the more likely it is to be detected. If one replaces your SSL certificate with a known-to-them certificate, they can decrypt the traffic for your site from outside your server, from points you won't be able to detect or do anything about.
At the end of the day, Let's Encrypt makes the little green lock icon not mean what everybody assumes it does. Just because the packets on the wire are encrypted doesn't mean anything. Sure, a random person on the internet cannot see what that traffic is, or modify it. Random people on the internet aren't the ones to worry about. If the site's traffic is of sufficient value to target, that little lock icon doesn't mean shit; you could still be talking to a bad actor. People see the closed lock and think "nothing can be wrong here", when that's not remotely true.
Too late. If your BTC were in an exchange at the time of the fork/dup/whatever, the equiv BCC/BCH/whatever belongs to that exchange; they will never be yours if that exchange doesn't want to give them to you. (just like your BTC belongs to them... you don't own them anymore.)
Because it's a tangible, physical object in my possession that I physically transfer to someone else's possession. It does not require any 3rd party to authenticate, or verify, and it doesn't get recorded in a public f'ing ledger for all eternity.
Credit cards are analogous to a BTC exchange. For the majority of their transactions, no actual cash (BTC) is touched; at the end of the month, you pay (or are paid) the outstanding balance. Those sorts of "paper" transactions are nearly instantaneous.
But yes, all crypto currencies are doomed to failure by their very nature. Confirming a transaction has to be computationally expensive or the whole thing is too easy to break. The world is already wasting an unbelievable amount of energy on this bullshit.
This is the exact same as Bob having someone follow him around to introduce him as "Bob" everywhere he goes. If you don't already know the person doing the intro, we're back to square one. Let's Encrypt is functionally equivalent to self-signing: do not blindly trust. They do effectively nothing to validate the request or requestor. To continue with your example, this is like validating Bob by going to where "bob" says is his house and seeing "him" on the front porch. It's often far too easy for that to (a) not be Bob's house at all, and (b) not be Bob on the porch.
Many, MANY possibilities. BGP hijacking is one of the more complex ways. But compromising the server itself is far more likely. Poorly secured email accounts... poorly secured DNS services... poorly secured cloudflare account... DNSSEC cannot protect you from your own stupidity. (and most/much of the internet ignores it anyway)
The ability to run something on the server proves nothing -- it proves I can run a CLI command. That does not equal ownership, or authorization. There are hundreds of thousands of sites any script kiddie can break into to run a script, drop a file, add a header, etc. to "prove" who they are. Let's Encrypt certs are on par with self-signed certs (they should not be blindly trusted), except they present no warning to users.
That "vow" is paper thin. They make no promises that the cert was issued to a legitimate person. Email, DNS record, and file-on-webserver-somewhere are exceptionally weak means of authentication. Sure, those things are found everywhere, but not in any important places. (that's why banks and phone companies mail your PIN on a piece of paper.) A rapidly growing log file is NOT vetting a damned thing.
And no, they don't leave the "user" to make any decisions at all. Do you know who signed the cert for every HTTPS site you've ever accessed? Even the one's that aren't on the URL bar -- the one's inside the HTML for ad services, or those millions of dumbass social media icons? The simple truth is almost no one bothers to see who signed what. The browser throws up a lock icon, doesn't turn the bar red, and doesn't present any warning dialogs. It makes people think things are perfectly secure when they absolutely aren't. Sure, the traffic is encrypted so anyone at random can't spy on you. However, there is zero guarantee you're talking to who you think you are.
It was about the same speed as filling a gas tank. While it looked good, and worked perfectly for the demo, it has all kinds of problems in the real world, which is why it never went anywhere.
Of all those things, corruption is the only one that's true. But each message is it's own file in the various spool directories. The various db's that can be corrupted can also be completely regenerated from the spool. I've done it many times; never lost a message.
what "separate configuration files"? My install (granted, it's old) has TWO config files (cyrus.conf and imapd.conf -- and the sasldb but that's systemwide)
Behind the scenes, yes, cyrus has many files. But you don't mess with them.
IETF decided that rather than do piecemeal solutions, they'd do one cleanroom implementation of the internet protocol using everything that had been learned over the decades of IPv4 usage.
HAH! They actively ignored much of what had been learned, and further, ignored what enterprises actually used. They put zero effort into how to get there -- backwards compatibility, migration paths,... And they gave zero consideration to any aspect of security. IPv6 is the horribly broken, constantly changing ball of shit that it is because of the design-by-committee pile of personal projects and agendas that were nailed together and called a protocol. There were many proposed methods of extending IPv4 address space, but it was agreed to create a new protocol to fix more than just addressing. In the end, we still have to build a new internet -- after decades, we still haven't.
In a word, NO! In fact, it will cause windows to fall back to using teredo, etc. to fake IPv6 connectivity. One must take active measures to block that shit from the network. Turning off those interfaces within windows will *NOT* keep them turned off.
#1 - Wrong. This is often trotted out, but an outsider cannot find every machine on your network with just the prefix or a single address. Once inside your network (compromised host), it's possible, but far from dirt simple. #2 - It's as tested as anything else. #3 - True, but you can attack anything that has a NAT map as well. And this is partially why privacy extensions exist (your address changes regularly) #4 - Wrong. This was a basic requirement of early IPv6 standards. It's now "optional", but present in many stacks. #5 - I'd say it's "full assed" by the few ISPs that bother to offer it at all.
Don't blame M$ and Google for what was a basic, founding tenant of IPv6... "None of this bullshit NAT!" And from a second chair in the room, "yeah, and none of this G** D*** DHCP!" By the time we get around the room, IPSec (think all of OpenSSL) had been glued into the protocol. Many hard lessons completely unlearned -- SLAAC, RA's, multicast DNS, etc.
If you want something to blame on Google, ask them why Android doesn't support DHCPv6.
[On the subject of SLAAC: this wasn't such a bad idea on the surface. However, the types of limited machines SLAAC specifically called out were *NEVER* going to be able to run anything close to a standards compliant IPv6 stack. It's a very stupid optimization once all the other designed-by-committee bullshit was stapled together. And worse, to date it has simply cemented the completely anti-IPv6 mindset of 64/64 network/host divide. So much so, that Stupid(tm) has been built into silicon!]
Those professionals hate it because it's a constantly moving target. If IPv6 were one thing to implement, ONCE, they'd've done it long ago. However, that's not the case. Even today, it's a constantly changing ball of shit.
IPv6 is a different way to doing things. NAT does involve a "firewall" -- 'tho it's unlikely to be watching traffic with an eye to security. With IPv6, security is not automatic; firewall rules have to be manually crafted.
"every flavor"? You mean NAT? Shit we've all been using since the mid-90s? ISPs have been grasping at straws because they can't get any more v4 addresses, and still have to connect a growing number of users to the v4 internet. (and develop v6 CPE hardware and infrastructure, AND still get the v6 only connected to the v4 internet.) And their answer has been NAT as well; just on a scale beyond reason.
XP has an IPv6 stack, but I wouldn't go so far as to say it "supports v6". It only supports SLAAC. (pinning a static address is a pain in the ass, and doesn't always survive a reboot) There is zero GUI integration for managing it. The OS will not use it for it's own internal processes (namely DNS.) And Microsoft has never officially supported it.
It's also so hopelessly out-of-date, it only barely works. Very little of what is considered IPv6 today is supported.
Switches operate at layer-2. They don't give a shit what layer-3's you run through your network. You may not be routing IPv6, but I can all but assure you IPv6 is present on the link. (if you have windows machines (newer than XP), you DO have v6 in your network.)
Perhaps. But the key here is that admins often are completely blind to IPv6 and various shit systems (and users) do to enable IPv6. (I'm looking right at you Microsoft!) VPNs? Sure. And many will block them.
Slashdot Mirror
If your car is worth anything at all, odds are someone will desire to take it. I've seen videos of people stealing various makes of BMW via diag hacks, made easier by alarm blind spots. And it's not limited to high-ish end makes; bog-standard hondas, vws, and fords are stolen and stripped all the time.
It gets much easier with "OnStar"... that's a radio with complete control of the car.
The ability to access your server may be limited -- and the more it's used, the more likely it is to be detected. If one replaces your SSL certificate with a known-to-them certificate, they can decrypt the traffic for your site from outside your server, from points you won't be able to detect or do anything about.
At the end of the day, Let's Encrypt makes the little green lock icon not mean what everybody assumes it does. Just because the packets on the wire are encrypted doesn't mean anything. Sure, a random person on the internet cannot see what that traffic is, or modify it. Random people on the internet aren't the ones to worry about. If the site's traffic is of sufficient value to target, that little lock icon doesn't mean shit; you could still be talking to a bad actor. People see the closed lock and think "nothing can be wrong here", when that's not remotely true.
Too late. If your BTC were in an exchange at the time of the fork/dup/whatever, the equiv BCC/BCH/whatever belongs to that exchange; they will never be yours if that exchange doesn't want to give them to you. (just like your BTC belongs to them... you don't own them anymore.)
Because it's a tangible, physical object in my possession that I physically transfer to someone else's possession. It does not require any 3rd party to authenticate, or verify, and it doesn't get recorded in a public f'ing ledger for all eternity.
Credit cards are analogous to a BTC exchange. For the majority of their transactions, no actual cash (BTC) is touched; at the end of the month, you pay (or are paid) the outstanding balance. Those sorts of "paper" transactions are nearly instantaneous.
But yes, all crypto currencies are doomed to failure by their very nature. Confirming a transaction has to be computationally expensive or the whole thing is too easy to break. The world is already wasting an unbelievable amount of energy on this bullshit.
If I'm your ISP, that's a very small hurdle.
This is the exact same as Bob having someone follow him around to introduce him as "Bob" everywhere he goes. If you don't already know the person doing the intro, we're back to square one. Let's Encrypt is functionally equivalent to self-signing: do not blindly trust. They do effectively nothing to validate the request or requestor. To continue with your example, this is like validating Bob by going to where "bob" says is his house and seeing "him" on the front porch. It's often far too easy for that to (a) not be Bob's house at all, and (b) not be Bob on the porch.
Many, MANY possibilities. BGP hijacking is one of the more complex ways. But compromising the server itself is far more likely. Poorly secured email accounts... poorly secured DNS services... poorly secured cloudflare account... DNSSEC cannot protect you from your own stupidity. (and most/much of the internet ignores it anyway)
The ability to run something on the server proves nothing -- it proves I can run a CLI command. That does not equal ownership, or authorization. There are hundreds of thousands of sites any script kiddie can break into to run a script, drop a file, add a header, etc. to "prove" who they are. Let's Encrypt certs are on par with self-signed certs (they should not be blindly trusted), except they present no warning to users.
That "vow" is paper thin. They make no promises that the cert was issued to a legitimate person. Email, DNS record, and file-on-webserver-somewhere are exceptionally weak means of authentication. Sure, those things are found everywhere, but not in any important places. (that's why banks and phone companies mail your PIN on a piece of paper.) A rapidly growing log file is NOT vetting a damned thing.
And no, they don't leave the "user" to make any decisions at all. Do you know who signed the cert for every HTTPS site you've ever accessed? Even the one's that aren't on the URL bar -- the one's inside the HTML for ad services, or those millions of dumbass social media icons? The simple truth is almost no one bothers to see who signed what. The browser throws up a lock icon, doesn't turn the bar red, and doesn't present any warning dialogs. It makes people think things are perfectly secure when they absolutely aren't. Sure, the traffic is encrypted so anyone at random can't spy on you. However, there is zero guarantee you're talking to who you think you are.
It was about the same speed as filling a gas tank. While it looked good, and worked perfectly for the demo, it has all kinds of problems in the real world, which is why it never went anywhere.
Of all those things, corruption is the only one that's true. But each message is it's own file in the various spool directories. The various db's that can be corrupted can also be completely regenerated from the spool. I've done it many times; never lost a message.
what "separate configuration files"? My install (granted, it's old) has TWO config files (cyrus.conf and imapd.conf -- and the sasldb but that's systemwide)
Behind the scenes, yes, cyrus has many files. But you don't mess with them.
HAH! They actively ignored much of what had been learned, and further, ignored what enterprises actually used. They put zero effort into how to get there -- backwards compatibility, migration paths, ... And they gave zero consideration to any aspect of security. IPv6 is the horribly broken, constantly changing ball of shit that it is because of the design-by-committee pile of personal projects and agendas that were nailed together and called a protocol. There were many proposed methods of extending IPv4 address space, but it was agreed to create a new protocol to fix more than just addressing. In the end, we still have to build a new internet -- after decades, we still haven't.
In a word, NO! In fact, it will cause windows to fall back to using teredo, etc. to fake IPv6 connectivity. One must take active measures to block that shit from the network. Turning off those interfaces within windows will *NOT* keep them turned off.
Until you reboot. Or install virtually anything from Microsoft. (read: they won't STAY turned off.)
#1 - Wrong. This is often trotted out, but an outsider cannot find every machine on your network with just the prefix or a single address. Once inside your network (compromised host), it's possible, but far from dirt simple.
#2 - It's as tested as anything else.
#3 - True, but you can attack anything that has a NAT map as well. And this is partially why privacy extensions exist (your address changes regularly)
#4 - Wrong. This was a basic requirement of early IPv6 standards. It's now "optional", but present in many stacks.
#5 - I'd say it's "full assed" by the few ISPs that bother to offer it at all.
Hell, Windows XP enables them by default. (once IPv6 is installed)
Don't blame M$ and Google for what was a basic, founding tenant of IPv6... "None of this bullshit NAT!" And from a second chair in the room, "yeah, and none of this G** D*** DHCP!" By the time we get around the room, IPSec (think all of OpenSSL) had been glued into the protocol. Many hard lessons completely unlearned -- SLAAC, RA's, multicast DNS, etc.
If you want something to blame on Google, ask them why Android doesn't support DHCPv6.
[On the subject of SLAAC: this wasn't such a bad idea on the surface. However, the types of limited machines SLAAC specifically called out were *NEVER* going to be able to run anything close to a standards compliant IPv6 stack. It's a very stupid optimization once all the other designed-by-committee bullshit was stapled together. And worse, to date it has simply cemented the completely anti-IPv6 mindset of 64/64 network/host divide. So much so, that Stupid(tm) has been built into silicon!]
Those professionals hate it because it's a constantly moving target. If IPv6 were one thing to implement, ONCE, they'd've done it long ago. However, that's not the case. Even today, it's a constantly changing ball of shit.
IPv6 is a different way to doing things. NAT does involve a "firewall" -- 'tho it's unlikely to be watching traffic with an eye to security. With IPv6, security is not automatic; firewall rules have to be manually crafted.
"every flavor"? You mean NAT? Shit we've all been using since the mid-90s? ISPs have been grasping at straws because they can't get any more v4 addresses, and still have to connect a growing number of users to the v4 internet. (and develop v6 CPE hardware and infrastructure, AND still get the v6 only connected to the v4 internet.) And their answer has been NAT as well; just on a scale beyond reason.
XP has an IPv6 stack, but I wouldn't go so far as to say it "supports v6". It only supports SLAAC. (pinning a static address is a pain in the ass, and doesn't always survive a reboot) There is zero GUI integration for managing it. The OS will not use it for it's own internal processes (namely DNS.) And Microsoft has never officially supported it.
It's also so hopelessly out-of-date, it only barely works. Very little of what is considered IPv6 today is supported.
RFC 6598 -- http://tools.ietf.org/html/rfc...
Switches operate at layer-2. They don't give a shit what layer-3's you run through your network. You may not be routing IPv6, but I can all but assure you IPv6 is present on the link. (if you have windows machines (newer than XP), you DO have v6 in your network.)
Perhaps. But the key here is that admins often are completely blind to IPv6 and various shit systems (and users) do to enable IPv6. (I'm looking right at you Microsoft!) VPNs? Sure. And many will block them.