Like when I browse a website using SSL from my laptop that is connected to my router using WPA2. My router talks to my ISP using IPsec.
Is that more secure or do these types of encryption have nothing to do with each other?
Ulkoma, the other answers are technically correct (at least, I think they are; I am by no means as much of an expert re. the specific characteristics of various encryption standards as the other answerers). But maybe you might be interested in a more "plain English" overview of the situation as well. So I'll try to put an answer out there along those lines.
Well, first it strikes me that maybe your question could actually be broken into two similar, but still somewhat different questions. Those being:
Does using different systems of encryption to protect your communications over different legs of a network connection make you more secure?
Does using more than one encryption protocols over the same network connection, such that encryption mechanisms are layered over each other for at least part of the journey between user and site/server, make you more secure?
The answers to those questions, in brief:
Yes, most definitely.
Yes..... kinda, sorta, to a degree that depends a little on how high your security needs are and other factors.
First, the question of different encryption measures over different parts of he connection that runs all the way from the computer to (let's say) some web site/server on the Internet. The answer here is crystal clear, I think: setting aside any odd & exceptional circumstances, you most definitely would prefer to have at least one "layer" of encryption technologies protecting the information going back and forth between you and that web server all the way along the length of that connection if possible. Alas, most connections made over the Internet today have some breaks in that protection, usually at the portion where your connection leaves your Internet Service Provider's infrastructure and is routed over the open Internet to some site/server you're visiting that doesn't have encryption enabled. In the absence of that, we'd certainly like encryption to be in place over as much of a connection as we can get. However, we at least need encryption in place in two, well, places:
(a) At portions of the connection where it would be especially easy for potential bad guys to monitor the connection and intercept info (or even add or change info!) sent over it to be protected by encryption; and (b) over the whole connection in certain situations where you may be sending or receiving really important/valuable data that really want to keep safe (for example, when your access your banking site to check your accounts)
So, let's take a look at your example. Okay, so the first part of your connection goes from your laptop or tablet to your wireless router, using wifi. Now, this wifi part of the connection is protected by that security/encryption standard called WPA2. Now, WPA2 when is set up properly (with a strong encryption key, dervived from a suitably random/uncrackable passphrase of string of characters of your choosing) provides good, strong security for your information as it passes over the airwaves to your router. There, your information is decrypted and the job of protecting it will be handed over to the IPsec protocol, which means your info with be encrypted there again and sent over your ISP's network. Now in the example you gave there's no mention of any other encryption after that to sit between your info and a potential eavesdropper. It will continue its journey on, over the rest of the connection, until it winds up hitting a site somewhere that didn't require encryption --via ssl/tls-- over the whole length (or allow you to go to a version that does use encryption over the whole length) of the connection. There are, of course, some secure sites that do require and do that (we'll talk about how in a sec), but still the majority do not. But if you're not on one of those sites, you're in a network connection to were you can't count on any encryption protocols to protection eavesdropping "on the wire" you could between your laptop and your ISPs network--obviously, that aspect is far, far beyond you knowledge and control-- and without the TLS added-in to protect your network connection all the way, your exchanges with the site have to be assumed to be entirely unsecured.
Now, note something here: in the example you just offered you mentioned two types of encryption-using protocols: WPA2 and IPsec. But each of those had its sort-of defined job, its part of the network connection it's supposed to handle in that scenario. And because each of those protocols had their own segments of the total length of the connection to protect, you wind up with different encryption protocols being used in the protection of one connection. Often, a number of different protocols will have a role in that way. So, yes, because you want to have as much of your link as possible protected by encryption and it's often the case that different protocols are used for different parts (both technological and geographic parts) of a connection path, yes, a secure connection will sometimes involve several different protocols protecting it at various times. Or something like an SSL/TLS protection
But point being, in the absence of an "end-to-end" measure (or almost end-to-end measure, as other commenters mentioned; it's complicated) like SSL/TLS, you are left with whatever protection much more limited-in-scope stuff like WPA2 gives you. Which still can be pretty important, depending on who and where your perspective eavesdropper is. So, yes.
Question 2: What about where "layers" of encryption exist together, protecting the same connection at the same place and time?
Okay, so here I have something to confess to you: a few concepts I used in answer #1 were really, really oversimplified. But especially that stuff about a "connection."
You see, in reality a "connection" is a really, really complex thing. When you open your browser and go to Google or wherever a whole lot of stuff is going on under the hood that you don't see. In fact, a connection is so complicated that to really dig into the subject--and also in part to help show relationships between some concepts--computer science people have separated the network connection-idea into layers. The OSI model, to be specific, separates them into seven:
Courtesy Wikipedia's OSI model page.
Look at that listing like you would look at a really complex layer cake where each layer has different qualities. Each layer of the cake/connection has its own characteristics, its own stuff going on. And, just like a cake, each layer has (not always, but very, very often) these different things going on simultaneously (or close enough to it). And all the layers, taken together and working both together and separately, make up a networking connection and allow electronic communication between computers as we know it to exist. For instance (still quite simplified), when I open a website and it sends a page to my computer electronic pulses that make up symbols are traveling over fiber optic cables, metal wires, and through the air (physical layer), in the form of data frames at various points (data link layer), as IP / TCP networking/transport packets (network & transport layers), and in the HTTP protocol (application layer) my browser can communicate in.
Now, if you go back up to that seven-layer chart and look and some of the various protocols that are used in each, you'll see some that probably look familiar. Among these, you'll see some that you know use encryption. And this is the second way that multiple protocols using encryption can work in one connection: different layers can be using different encryption protocols at the same time in parallel with each other. This is why some of the other answers talk about this encryption type at layer x and that encryption being on layer y, and why I use the concept of layers of encryption in one connection: because the different encryption protocols can and frequently do operate on the same connection at the same time.
A good, straightforward example: I fire up my laptop and want to access a document that's in a part of my work network that I have rights to access remotely. So, my laptop automatically handles encryption with my secure home WPA2 network (of course), then I launch my VPN software, which talks with my office's VPN/remote access router and establishes a IPsec-encrypted tunnel to connect me to my office's network. Then, moving around and accessing stuff in my office's network, I access something via browser that uses SSL/TLS to secure user sessions. At that point, someone physically near me (say, someone else in my apartment building) who wanted to break into my wifi session and eavesdrop on the work information I was working with at that moment would have to deal with WPA2 wifi protection, my VPN IPsec tunnel, and the SSL/TLS browser encryption.
(Also, just FYI, the concept of one single "connection" is, uh, also a huge oversimplification. Maybe it's better to think able the seven layers being like seven different strands that are rolled together to make one strong connection rope. Except, that, uh, to confess yet another oversimplification the seven strands can each have different links, of very, very different segment lengths that also very often don't match up with each other. Concrete example: right now on a physical layer-level the bits that make up these words are traveling through the air, then through the materials that make up my hope office router, then through the metal wires of an Ethernet cord to my ISP's modem, then...etc., while at the application level this page and I are talking in http format all the way from were I am to were the web server for this is.
Just a few points I thought you should know I kind of glossed over above. Like I may have said, computer networking is complicated.:) )
Anyway, okay, finally, let's get to the actual answer to question#2: does this multi-layered encryption situation, when it falls into place, actually make your information that you are sending across networks any more secure?
Well......it sorta depends.
The principle that all info sec people say (say) they live and die by--defense-in-depth--would suggest that the more layers of strong encryption we can layer on there, the better. Except ... many of the protocols we can talk about in the various layers are really strong protectors even by themselves. If we have something at one layer that seems to cover pretty much the whole length and breath of the connection, how much encrypting do we need going on at others? Great example of a strong practical in that way is an IPsec VPN. If I fire up my laptop and want to make a secure connection to my office's network, IPsec is a great tool for that. But if I do the strong VPN, does my need to worry about encryption of the wifi network I'm using diminish? If I use that VPN to do remote access to my office and connect with some server there that uses SSL/TLS to secure the connection from the server to my computer is that really necessary? One could point out that without the end-to-end SSL/TLS there would be a gap in the encryption coverage between the device at work that receives my VPN connection and lets me into the office network and the actual server where I'm getting something from. But come on, that's susceptibility only in a physical area-the space between those two machines in my office-that my employer should have good control of, right?
Personally, I side more on the side of wanting more simultaneous, strong layers of encryption than not. I like my defenders-in-depth to be deep and redundant, sometimes (yes) approaching the point of overkill, even. I'd much, much rather overestimate the capabilities of an attacker than underestimate. But people have different philosophies, coming down on different parts of the security spectrum. Helps keeps things interesting. And also, of course, some situations demand the very strongest security measures that can realistically be provided.
But to be honest, I think the personal opinion and outlook of the person ultimately responsible for security design in some situation tends to have more impact as a factor on what degree/intensity of measures that gets implemented than a lot of people in the security professions tend to want to openly acknowledge. But that's just my opining now...
Anyway, hope this proved helpful to some extent. ( Crypto people or encryption protocol super-experts: my apologies for the mangelings I've certainly made about the details of your technologies at points in this answer.)
Yes and no.
SSL offers end-to-end encryption between the application using SSL and the server to which you are connecting. It's a layer 6 protocol and may only provide security for that particular application.
In case of IPSec, it works at layer 3. It's mostly used to provide end-to-end encryption between different sites. For instance, if you have several applications communicating across a link, but those applications do not use any security protocols, you do not want to use the internet as any intermediary router can see the traffic as it's in the clear. IPSec solves this issue by providing a site-to-site encrypted tunnel. So the applications are still sending information in plain text, but before it leaves the site towards the other site, it is encrypted.
Now both are strong security protocols and, if implemented correctly, considered secure. Now if you are communicating across SSL and add IPSec then it's not considered more secure. SSL provides end-to-end security. Adding a layer of IPSec does not matter.
When using IPSec and adding SSL this may be different. IPSec only provides security up to a certain router after which the traffic will become clear again. Using SSL you can ensure that your data is secure until it reaches its final destination. If an attacker has access to a router after the traffic is de-crypted, then he can perform a MiTM, whereas with SSL this still would not be possible.
So adding IPSec to SSL does not provide extra security, but adding SSL to IPSec may offer better security, depending on circumstances.
It's probably worth clarifying that SSL provides encryption from your client to the SSL termination point which may not be the final destination server - it may be a load balancer or some kind of cache server in the route.
Also, because the encryption systems encrypt at different layers of the stack, they leak differing amounts of information into the traffic stream e.g. SSL leaks the final service destination port (usually 443 or similarly defined port). IPSec and SSL will therefore reveal different things about the underlying communications.
How useful the leaked information is however may vary.
Using SSL over IPSec will provide additional security over the public part of the route by hiding information about the communication above layer 3 by IPSec, and then protecting the communication once 'inside' the target network (and after the IPSec tunnel has been terminated) by SSL- assuming SSL terminates further inside the target network than the IPSec tunnel termination.
In principle, stacking SSL and IPsec is ok and gives a (very minor) security improvement.
But there is one concern: vulnerabilities in encryption software, such as Heartbleed. Who knows what other vulnerabilities are lurking in OpenSSL, waiting to be discovered, or even being actively exploited? By having two pieces of encryption software, you now have double the chance that one of them contains a vulnerability.
It's for this reason that people usually keep it simple and only use a single encryption layer.
I don't see how you can do ipsec over ssl. But it's not the mixing of different types of encryption that secures your data. It is the layering of different forms that does so. The endpoints are invariably then the likeliest of targets.