13:33 Security (encryption) traffic | |
| In parallel with the development of technologies to protect Internet traffic from unauthorized access and develop technology to intercept protected traffic. Intercept and study the unencrypted user's traffic no longer is easy, even for the average user. Almost everyone knows the word "sniffer". Theoretically protected by SSL / TSL-compound by conventional means is impossible to intercept. But is this true? Actually - not quite. Yes, the encrypted traffic is theoretically impossible to decipher, although again in theory at very high need and desire, and this traffic can be decrypted, pick up the keys. However, this requires such costs of resources that the urgency of breaking stored only, perhaps, at the governmental or military level:) When using a secure connection (very simple example - HTTPS) all traffic between communication points in the network is encrypted on the sender side and decrypted on the recipient side. Encrypted traffic going in both directions. In order to encrypt and decrypt would like a pair of keys (asymmetric encryption). Public key used for encryption and is transmitted to the recipient data, and private - to decrypt, it stays with the sender. Thus, the nodes between which is established SSL-connection, exchange of public keys. Further, to improve the performance formed a single key that is sent in encrypted form and is used for both encryption and decryption on both sides (symmetric encryption). And how do they do? Normally - on the same channel on which will continue to go encrypted traffic. And the key exchange is open. In the case of HTTPS server key is associated with a certificate that the user is invited to review and accept. And this is just a certificate and can intercept any intermediate server in the way which is a certificate in cleartext (proxies, router). To continue to "read" all user traffic, the intermediate server certificate to replace his own. Ie it simply connects to the client himself with his certificate, and at the same time, connects to a remote server. Client comes "left" certificate from the server, the attacker, and the browser informs the user about the dangers (such certification is not always signed). The user is a choice: accept the certificate and work with the site, or to refuse to accept it, but also work with the site then no longer happens. Sometimes users generally ignore the contents of the certificate and automatically take all before them. If the user accepts the certificate is forged, then the traffic will go as follows: client <= SSL-connection => server-wiretapping <= SSL-connection => destination server Ie intermediate server will receive all of your "protected" traffic in the clear. It should also be noted that the transfer certificate is in the beginning of each session HTTPS. In the case of a secure SSH when you first connect to a server on the client remains the key server and the server - a key client. These keys are transferred between the client-server only once, when first connecting. If in this case, SSH-Traffic will try to intercept, then the client and the server refused the connection because it violates the keys. Since keys can be transferred between the client and server roundabout way (via a secure channel, or on external media), this connection method is relatively safe. It can only block, forcing the user to work in the open. It is worth noting what has long been sold so-called "information security solutions company" that intercepts all traffic passing through the office proxy server, and "read" it. Programs are looking for the presence of certain phrases or certain types of information in the data stream from browsers, email programs, ftp-clients, instant messengers office staff. Moreover, these programs are able to distinguish and properly handle the most different kinds of information interaction with servers. In particular, they check and secure SSL-traffic by spoofing certificates. With the development of one such system I've encountered almost immediately. But the path of salvation from the surveillance is. Through established SSH-connections can be sent to any required traffic, which with the SSH-server is already in the clear to go on the endpoint. This method is called SSH-tunneling (tunneling). So it is possible to secure the traffic over an insecure channel, but this approach makes sense only if the proxy server with a raised and tuned for tunneling SSH-daemon. And organizing is simple enough. SSH-client connects to the server is configured to wiretap any given port on the local machine. This client will provide the service SOCKS5-proxy, ie, its use can be configured in any browser, e-mail programs, IM-oh, etc. Through SSH-tunnel packets to arrive at the server, and with him went to the target server. The scheme is obtained as follows: [localhost: client <=> proxy] <== SSH-connection ==> Server <=> target server Another way to protect traffic - VPN-channel . In using it easier and more convenient SSH-tunneling, but the initial installation and setup is more complicated. The main convenience of this method is that the programs do not need to prescribe a proxy. And some soft and does not support a proxy, VPN, and therefore only fit. In practice there are two options work. The first - the purchase VPN-akkanuta, which is sold specifically for this purpose (encryption over insecure channel). In this case, the sale usually accounts, which must connect to the protocol PPTP (regular VPN, which is implemented, for example, in Windows) or L2TP. The second option - buying VDS-server (virtual dedicated server) with any distribution of Linux on board and lift it to VPN-server. VDS could be Russian or American (just do not forget about overseas pings), cheap ($ 5) and weak or expensive and powerful. At VDS put OpenVPN-server and the computer up OpenVPN-client. For Windows, there's even guishnaya version of the client. If you decide to use the version with OpenVPN, that is, for example, this simple step by step instructions for raising a server (Debian). Install the client is even easier, especially under Windows. Mark is just a nuance. If all the traffic you want to put on the created VPN-connection, it is required to register default gateway to gateway VPN (redirect-gateway option in the config client), and if only a portion of traffic (on some hosts), then we can prescribe the usual static routes to these hosts ( on IP; example, route add-p 81.25.32.25 10.7.0.1). To connect to OpenVPN key exchange occurs in manual mode, ie transporting them from the server to the client can be absolutely safe. So, SSH-and VPN-connections can be almost completely guarantee the security of your bandwidth when you move over an insecure channel. The only problem that may arise in this case - is a ban on the SSL-traffic on the corporate firewall. If SSL-enabled traffic At least one of any port (usually credit default 443), then you already can potentially raise and SSH-tonel, and VPN-connection, set the appropriate daemon on your VDS at the port. | |
|
| |
| Total comments: 0 | |