Password on the Internet

The Internet introduces a large number of different security vulnerabilities. The organizations or individuals you are communicating with may be organizations or individuals you do not know or may pretend to be other organizations (individuals. You do not have to worry too much about such problems, but it is necessary to take appropriate preventive measures to prevent losses caused by various means, including funds transfer, incorrect authentication results, loss of confidential information, and breach of contracts. Password is mainly used to deal with such risks. This article describes some protocols and related mechanisms that have specific relevance with Internet activities (including email.
Internet-related protocols and mechanisms

Request comments (request for comment (RFC ))
Request comments are formal Internet documents managed by the Internet network engineering task group (IETF). They serve as a way to disseminate Internet Engineering Consulting and opinion information. RFC describes open standards to benefit those who may wish or need to use them for communication. They are compiled by volunteers participating in different working groups and published in different locations, especially on the IETF site. For more information about TLS, see the description below.

IPSec
The ietf ip Security Protocol workgroup is currently defining additional IP security protocols, which provide authentication, integrity, and confidentiality services for the IP datagram layer. It is described in several RFC. Although it is intended for IP v.6.0, it can also be used for IP v. 4.0 (IP v. 4.0 is the current standard and uses addresses in four groups, for example, 192.168.1.3 ). It is intended to serve as a basis for security for Internet communications (such as VPN and encapsulation tunnels. Some vendors and software organizations are developing or providing products that integrate IPSec. For example, SSH Communications Security in Finland has a product called IPSec express which was designed to facilitate the development of IPSec-compliant electronic commercial applications. Since June 1999, the NetBSD Foundation has merged the IPsec code into the NetBSD distribution edition.

Although IPSec has become a de facto standard for the implementation of Internet security, it has been criticized by Niels Ferguson and Bruce Schneier (the latter is the designer of blowfish passwords widely concerned. Ferguson and Schneier believe that IPsec has become overly complex and tends to be difficult to manage. They said that the problem here is that the content added to IPSEC does not enhance the product in the desired way, but is to meet the wishes and expectations expressed in a wide range of interests. They compared this method with the method adopted by NIST in an out-of-date manner to choose a new security algorithm to replace DES. In the article on symmetric cryptography (Part 1).

Their conclusion is that IPSec is much better than any previous security protocol, but claims that the complexity inherent in its design has led to a lot of ambiguity, conflict, inefficiency and other weaknesses, and produced an extremely difficult set of specifications. As a result, they doubted whether it could generate a truly secure operating system. They put forward a lot of specific suggestions, but recognizing the poor quality of the document and the excessive complexity of the Protocol means that they do not fully understand the system, which is a great challenge to their experience and authority. As they pointed out, it is impossible to make 90% of security work. Frankly speaking, they are very dissatisfied with using the current form of IPSec, but are more opposed to any other current protocol. Therefore, IPSec is recommended when these other protocols cannot protect network security.

Secure HTTP (secure HTTP (S-HTTP ))
Secure HTTP (S-HTTP) is an HTTP Security extension that runs at the application layer. It aims to provide confidentiality and authentication while supporting non-repudiation and multiple cryptographic algorithms and key management mechanisms. Although the initial key agreed by the Kerberos server can be obtained before the session, or the key to be used by the next session can be generated in one session, RSA is usually used for initial key negotiation.

Secure Socket Layer (Secure Sockets Layer (SSL ))
Secure Sockets Layer (SSL) is a handshake protocol developed by Netscape Communications to provide security and confidentiality for Internet sessions. It supports server and client authentication, is designed as a negotiated encryption key, and authenticates the server before any data is exchanged. It uses encryption, authentication, and Mac to maintain the integrity of the transmission channel.

Although SSL is best suited for HTTP, it can also be used for FTP or other related protocols. It runs on the transport layer and is independent from applications, so related protocols such as ftp or HTTP can be placed on this layer. Use the initial handshake to authenticate the server. In this process, the server submits the certificate to the client and specifies the preferred password to use. Then, the client generates the key used during the upcoming session, submits it to the server, and encrypts it with the server's public key. The server uses its private key to decrypt the message, restore the key, and then sends a message encrypted with the key to authenticate itself to the client. Use this accesskey to exchange encrypted data.

You can use the second stage (optional) to further increase security. Here, the server sends a question to the client and returns the digital signature of the question and the client's Public Key Certificate to the server.

In the query phase, RSA with MD5 for message digest is usually used for execution. You can also use various symmetric passwords, including DES, Triple DES, idea, RC2, and RC4. The public key certificate complies with the X.509 standard. Current SSL version is 3.0.

Previous SSL history gave a warning about the importance of peer review for cryptographic products, especially Ian Goldberg and David Wagner (two PhD students at the University of California) I wrote an article in the Dr Dobb's journal February 1996, explaining how they cracked the encryption system and used it.

At that time, Netscape did not want to publish any information about the structure of SSL or the cryptography and other methods used by SSL. Goldberg and Wagner applied reverse engineering to related algorithms. They found that the seeds used to generate pseudo-random numbers (and then generate the key from the random number) depend on the date, process ID, and parent process ID. It is relatively easy to obtain these two identifiers, at least for any user who has an account on the unix machine running the browser. The sniffer can collect information packets in one second. This information reduces the number of possible seeds to 1 million, and then uses HP 712/80 to crack these values in less than half a minute.

It is very difficult to generate a real random value using a computer, so the program that requires a random number will generate a seed as randomly as possible, and then use the pseudo-random number generator (PRNG) generate a pseudo-random number from this seed. However, the same seed of a specific PRNG will generate the same number, which is used in the encryption system algorithm accordingly and will generate the same key. This is not a weakness for itself, but it is important to make the original seeds generate as random as possible. Applications often encounter unpredictable or repetitive events, such as random electronic noise in the chip, noise diodes, the operation of a disk drive, user-defined keys, or mouse movement. Under such special circumstances, it is reasonable to use three elements to create seeds, and the designers at the beginning obviously did the same, however, further analysis reveals some limitations. Asking others to challenge such mechanisms is precisely the value of peer-to-peer review. If a system is eventually considered to be good, this is critical.

Transport Layer Security (TLS ))
Transport Layer Security (TLS) protocol is a draft of the IETF standard, which is based on and similar to SSL. Its primary goal is to provide confidentiality and data integrity between two communications applications. It consists of two layers. The lower layer is called the TLS record Protocol and is located on a reliable transport protocol (for example, TCP. This layer has two basic features. Specifically, this connection is dedicated and reliable. It is used to encapsulate more advanced protocols, but can also be used without encryption. When encryption is used, the generated keys used for this encryption are dedicated to each connection. These keys are based on keys negotiated by another protocol (for example, higher-level TLS handshake protocol.

The TLS handshake protocol provides connection security with three basic features: asymmetric cryptography can be used to authenticate the identities of peer-to-peer authentication, and shared key negotiation is secure and reliable.

Like SSL, TLS is independent from the application protocol. The types of encryption algorithms used are similar to those used by SSL. However, the TLS standard leaves the decision on how to start the TLS handshake and how to explain the certificate to the designers and implementers running on the upper-layer protocols for determination.

The purpose of the TLS protocol is to prioritize password security, interoperability, and scalability. The final goal means that TLS provides a framework that can be introduced into the framework when new and improved asymmetric encryption and other encryption methods are available.

Wireless Transport Layer Security (WTLS ))
The security layer protocol in the Wireless Application Protocol (WAP) architecture is called Wireless Transport Layer Security (WTLS )). It operates on the transport protocol layer. It is modular and whether to use it depends on the security level required by the given application. WTLS provides a secure transmission service interface for the upper layer of WAP to protect its transmission service interfaces. In addition, it provides an interface for managing secure connections.

WTLS is very similar to TLS, but it is most suitable for narrowband transmission networks with relatively long wait time. However, it adds some new features, such as datagram support, optimized handshakes, and key refresh. Like TLS, TLS primarily aims to provide confidentiality, data integrity, and authentication between two applications that are communicating.

Secure Electronic Transaction (SET ))
The Secure Electronic Transaction (SET) protocol is developed by the Visa and MasterCard International Consortium as a method for conducting secure bank card transactions on the open network. It supports des and triple DES for batch data encryption, and supports encryption of the public key and bank card number with RSA.

Although set is considered safe, it is relatively slow due to security. In addition, a digital certificate must be correctly issued, so it cannot be used in a simple and special way like SSL or TLS. For these reasons, and many banks pass the consequences of risks and bank card security vulnerabilities to their commercial customers, it is a problem that the adoption of set is far from being imagined. However, there are indications that this is changing.

Secure Wan (secure Wide Area Network (S/WAN ))
The security Wan initiative is promoted by RSA Data Security and aims to facilitate the extensive deployment of Internet-based Virtual Private Networks (VPN. S/WAN supports IP-level encryption, So it provides more basic and lower-level security than similar SSL or TLS. VPN is a mechanism designed to allow users to maintain secure tunnels between users when using the Internet. For example, you can connect to a remote office at a low cost without increasing costs, or avoid point-to-point inconvenience caused by the use of dedicated leased lines. Messages transmitted through the channel are encrypted, so they should be safe and can be effectively intercepted by third parties. In fact, and partly because the development of different standards is designed to be one or another, it brings competitive benefits, causing serious disconnections between theory and practice, especially in terms of interoperability. The S/WAN initiative is an attempt to bring order to the chaos.

Although the original S/WAN initiative is no longer in progress, there are very similar initiatives in the Linux FreeS/WAN and Virtual Private Network Consortium initiatives. FreeS/Wan is an IPsec (see the previous description) Implementation in Red Hat Linux, and provides a Linux VPN implementation that can be made effectively according to gnu gpl.

Secure Shell (SSH)
Secure Shell (SSH) is a protocol currently being standardized by the IETF's secsh Working Group. It allows secure remote access on the network. You can use multiple methods to authenticate the client and server and establish an encrypted communication channel between systems that support SSH. Then, this connection can be used in many aspects, such as creating a VPN or creating a secure remote login on the server to replace similar telnet, rlogin, or rsh.

Encrypted email
Why do we mention encrypted emails? In many cases, it is no different, but users should understand that sending a plaintext email is like sending a postcard that anyone can read. An email is transmitted on an uncertain, segmented route, and can be viewed easily at many points along the route. In some time, it is stored in the semi-public area of the network mail server or the storage of the ISP. Emails may also be sent in batches by mistake or by mistake: a network manager's article is included in the Network News Journal, he mistakenly sent an image with "I am very munchable" next to his profile picture to every printer in the office building, this image was originally a message from his wife's private T-shirt. Of course it is not an email, but it is also very prone to such problems, and it will also cause embarrassment. Many products provide secure email, which is either provided as a complementary product using PGP (pretty good privacy (PGP), which will be discussed in detail later, you can either add a digital signature and encryption tool to a mail message created using an appropriate client (for example, Netscape) using a protocol such as secure mime (S/MIME. Mime (Multipurpose Internet Mail Extensions) is a standard Internet Mail format, it allows enhanced text, audio, graphics, video, and similar information in an email message in a standardized format. However, mime does not provide any security elements-S/MIME added to these elements. S/MIME has been recognized by many online and messaging ISVs, including Netscape, Qualcomm, Microsoft, Lotus, Novell and other ISVs. You can obtain information from IETF.

However, introducing encrypted emails to large organizations may cause some new problems. Anti-Virus products may not necessarily identify encrypted dangerous attachments. In addition, scanning programs and firewalls (which may work to prevent access to organizations or departments with confidential or illegal information) may have similar issues.

One solution may be to encrypt and decrypt the email on an external gateway, but this will make the email remain unencrypted when transmitted over the company's network, which may not be appropriate. In any case, no matter What email client is being used, many email encryption packages work at the desktop level as a subsidiary tool for these clients. However, by dispersing specific content security policies, desktop scanning will make the problem more complex and difficult to enforce. Another option-usually clumsy and resource-consuming, but appropriate in some environments-may be to send copies of emails to a centralized mailbox for decryption and check, encrypted emails are allowed. The difficulties include traffic doubling, message transmission latency, real-time user information, and possible inconvenience. Giga group raised this issue in a recent discussion. The most satisfactory solution is to encrypt the email and then send it to the repeater, where it decrypts it, and check to determine whether the security policy is met and whether there is any virus, encrypt the specified recipient, and re-send it as appropriate. As in the past, the best way is to weigh the risks and the cost and inconvenience of the proposed solution.