Security misconceptions

People have tons of misconceptions about security and what makes them safe and not safe. The Internet has been around for a while now and it still amazes and people probably no less on average mistaken as to how things really work.

SSL (secure socket layer) is a good example. Most of you have seen the http and the https at the beginning of a URL. Your supposed to be using SSL when it says https. Couple of issues. What level of encryption is being used is different from site to site and especially if you connect to a server outside the US. It can range from something like 48bit to thousands. If the server is outside the US I think the current law is 256 bits. But not 100% on current law. Ok, well it has been proven that a lot of the lower ones can be broken or attacked fairly reasonably. Which is why 256 and higher is usually suggested.

However, there is a real problem with that. Most attacks aren't even preventable with SSL. Very few people packet sniff to attack someone. you would have to have a pretty good direct link on the network to get all guaranty you are going to get all the packets. Packets can take different routes and arrive in different orders. Which is why they have transport layers such as TCP/IP to help get them back in order so you can read your messages.... If you create your own packet network using UDP/IP you are taking the responsibility of ordering them and sorting them.... there are others. But I am not going to list them. The point is you need to understand it is easier for someone to get virus or back door on your system than try and packet sniff you in most cases reliably. That depends some on the network you are attached to as well. If you are connected via cable broad band verses DSL it is easier for someone to do it.

So why does SSL exist for the most part. Money. They want to get license certificates and so on to sites so that money can be made from it. If it was purely about Internet safety they would make getting a license free.

SSL doesn't prevent people from hacking your computer or the server your info was sent to. All it does at best is encrypt the information while it is in route between the two points.

I can make a fairly decent list these days of does and don't and misconceptions people have when it comes to security and protecting private info and actually being safe verse thinking you are safe.

https/SSL makes it much more difficult for someone to use DNS tricks to impersonate another web site. DNS cache poisoning attacks and other DNS based attacks were very popular at one time.

Of course, it only works if the user is paying attention at least a little bit, and notices the missing https and lock symbol.

I think you're underestimating the risk of someone on the inside of one of the network providers tampering with your data as it passes through the internet. Or someone outside the network provider who's hacked into some of their equipment.

It does NOT protect you from any kind of attack other than the ones it's supposed to cover. If someone has hacked the website on the other end or your own PC, you're in trouble. It can be like putting a big fancy lock on the front door of your house, but the window on the back of your house doesn't lock.

DNS based attacks were never popular they were brought to the publics attention short time back. DNS attacks most primarily fixed by up dating DNS server code. The issue came to light when a group decide to prove it was theoretically possible. In less than 1 month 90% of the servers had been updated to resolve the issue.

SSL is no more than a public key certificate supposedly proving you are who you say you are and the encryption is in effect. Problem it is possible to self certify. You just need to know what you are doing and how to get your certificate recognised. Most registries that verify certs are sent with the browsers these days. But you can be added.

The only attach it can protect you from at all is packet sniffing. I explained for the most part people don't do that because it is far easier to go to either end and get the info. Even if they didn't have SSL in place going to the end and getting the info is easier.

The reason it is ineffective against DNS cache poisoning is well simple there is nothing at all to verify the path. The way DNS cache poisoning works is you would send the up date info to a DNS server as to what a domains IP adress info and so on is. For example I run several DNS servers here on location. If I was to update the DNS with the wrong ip to my webservers then when someone did a dns request from it it would give out the wrong ip. On my servers that isn't going to happen because it doesn't update in that manor. But if I updated to my ISPs server with the wrong info anyone that did a request for my info for my servers could be mis directed to another site / server pretending to be mine. Just because a site looks right doesn't mean it is. You wouldn't know you are at the wrong site unless maybe you checked the certificate manually they use and checked the ipaddress.

So pretend RB gets his own cert for RB makes his website look exactly like mine but uses the RB cert. Your system isn't going to warn you of jack because well it see RB as RB the only thing is your browser is going to ID his sites which ever site he is mimicing. In some cases you have to be on the right network to even do the update.

The practicality and gain you would get from doing it made it hardly used.

Packet tampering and packet sniffing. Why it isn't common place or practical.
First it requires you to locate a network connection or point you can actually read the packets. Next you have to determine which ones are relevant among millions. You have to get them in order.

I would suggest you start by grabbing a book on socket programming were you can learn about TCP/IP and UDP/IP layers and so on.

Depending on the type of network set-up your target is using packet sniffing can mean a need to physically trespass meaning added danger of getting caught and more evidence you would leave behind.

If they are on a line network or ring network were everyone is sharing a connection the packets pass by each persons connection which is what you get when you use cable modems. DSL has an individual loop that runs back to a D-SLam which then joins the back bone at the point. If you were in an office 10 or more years ago ring networks using coaxial cable was not uncommon, back sniffiing not so hard. Think about that DSL loop your 2 main points to read it are going to be one either end meaning your likely going to need to trespass on telco property or the owners property. They also have fiberoptic these days, twisted pair eithernet and so on. that can be ran to properties and others. Then if it isn't a nice neat office connection or cable modem ... you are going to need hardware to connect that will not mess up the current connection.

Packets on the open internet do not all follow the same path. You may have the first packet take route "A" the next 5 may take route "B" and they can go any number of ways. So unless you can get to a point were all the packets are going to come through a single point the most you can do is corrupt data. You won't be able to reasonably change it and insert a virus in another file or any of the crap you see them talk about on TV to do that is a hell of a lot harder. the way viruses and crap get into files and stuff is "always" end point.

you use packet signing to determine if packets have been corrupted. meaning a hash is attached to each packet. It is almost impossible to beat it when done right. Secondly, if you corrupt a packet all is going to happen on a properly set up system is the receiver will send a request for the sender to resend that packet.

Can you block someone from receiving packets sure lots of ways. The easiest is Denial of service and the easiest for someone to detect and send the cops over to pick your stupid rear up for. All a DOS attack is usually sending enough requests or Packets their system can't go through them all and it fills the buffer up... out does what the network connection can handle... At some point packets start getting lost when they can't get through.

however, some people have gotten good at building virus that they can then use a trigger command to target a site and send large amounts of request and data to the target. By doing this they can use millions of computers and target pretty much anything. Yes, even shut down a nations network effectively.

99.9999% of people will never rate high enough on an attackers list to both using packet sniffing.

I disagree that DNS poisoning was an unimportant threat.

DNS cache poisoning is not the only possible DNS attack. If, for instance, your ISP is compromised, you could easily be fed false DNS data. It's also possible that someone could hijack the domain registration itself. That's happened in a number of cases. The use of SSL authentication with a separate certificate authority provides an independent security check. Of course, someone could compromise a certificate authority, too.

I always get an alert if the SSL certificate is self issued. I can choose to accept or ignore it.

If the SSL certificate does not match the URL, I get an alert. Yes, if I DON'T look at the URL, a lookalike site may fool me.

I do not believe that you can count on packets not taking the same path. They may take a different path, they may not.

Let's face it though. If I send most people a link that says go to https://google.com, they won't notice that it actually goes to yahoo.com and it doesn't use SSL.

SSL/https adds significant security. It doesn't make you 100% secure. Face it, if you're running Windows, your ass is flapping in the breeze anyway.

Some of what you said is on. However, most DNS systems when the flaw was made public didn't just update from any place. There was security checks in place like expecting it from a specific ip address such as when you had main system mirroring.

The flaw seemed to be easier to implement against a single site. Say you were with JackISP and site RB was with JackISP or you had a means to get a connection on the ISPs side you might been able to get JACKIsps server to update thinking RB site was at a new ip address.

You are right also you can't count on packets going a different way but the more important issue is a hacker in between can't rely on them all coming past them. But there is a host of other issues that a hacker would have to contend with. Such as gaining access to a point he can monitor those packets. That is just start of issues they will have to deal with. If they physically break to a point they can directly monitor the packets on a network like I said before they are usually going to have to trespass. If they hack a system and get in and take over so they can monitor it their risk just went way the hell up and are very likely to get detected. Just think of all the traps and whistles on most linux servers, On some of my servers if you connect it is recorded, an attempt at connecting is recorded, if you run something externally it is recorded if you manage to down load something it will be coppied to another space and renamed, .... You would have to get in go through all the files cover up all the entries and so on and get back out and have some sort of program to reset everything to a normal state just not to be detect on that system. Think that is bad imaging trying to go through several layers of it.

If you are worried about someone doing it who has tell co access or something. The real threat when it comes to packet sniffing is dirty admin and network personnel or government agencies. From someone who worked for DOD/DLA they rather go to the source points it is easier.

Just look at the stuff like credit cards and so on that get stolen. Usually someone inside or B the server it was stored on wasn't properly pass-worded or it was just way to simple. That accounts for most of them. Then you got the ones were someone finds a code problem where they can initialize a buffer over run and run their own code. Or stupider yet, the site programmer allows any code to be entered in with out stripping server side code. Then you got to blame the admin for allowing to much access control to any single site....

There are plenty of large companies that self certify. Your browser isn't going to alert you because the certification part is already added in so it just accepts it. It isn't as hard as you want to believe to get where you don't pop up any warning.

Not to mention you can set up your own SSL authority or take a partner option with one of the companies offering it run it on one server and sell your self certificates.

I'm not saying it is entirely meaningless just it isn't need or as big of deal as they make it out to be. The idea was to scare the general public into thinking a hacker could easily get their CC this way and this was something sites should be using. That forced a lot of sites who didn't understand the way it all works into buying certificates.

Its scary when you really think about it.im still just learning and it dont help that im sucking at computers.late to the game and messing up all along the way.ive had my computer redone afew times.one quick lesson i learned is only let those you know you can trust mess with your computer.ive had afew quick lessons.thx for your info.it really helps

As someone who does computer security for a living, let me say SSL is good, and does what it is designed to do. Is it the ultimate in protection - no - far from it, but it does work.

You want perfect computer security - don't use a computer. Because any and all computers (both hardware and software) have vulnerabilities that can be exploited. The real answer is - how much risk are you willing to accept? A lot - then charge ahead in ignorance. A little - then do the basics, anti-virus, update your system, use ssl when available . . . None - get off the computer.

Just like the hobby - how much risk are you willing to take? If it is TGTBT - then it probably is.

Can we have that in English please??? LOL

I am sooo not a computer person!


KKA