Page MenuHomeMusing Studio
Files F10455521

No OneTemporary
Actions

View Options

diff --git a/.gitmodules b/.gitmodules
index 62f5059..039abed 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,7 +1,10 @@
[submodule "src/github.com/writeas/writeas-cli"]
path = src/github.com/writeas/writeas-cli
url = https://github.com/writeas/writeas-cli.git
[submodule "fonts/lora"]
path = fonts/lora
url = https://code.as/writeas/fonts-lora.git
branch = include
+[submodule "src/code.as/core/socks"]
+ path = src/code.as/core/socks
+ url = https://code.as/core/socks.git
diff --git a/src/code.as/core/socks b/src/code.as/core/socks
new file mode 160000
index 0000000..5be269b
--- /dev/null
+++ b/src/code.as/core/socks
@@ -0,0 +1 @@
+Subproject commit 5be269b4e6645df01c78c8dfcfe5b5fa0d336591
diff --git a/src/code.as/core/socks/LICENSE b/src/code.as/core/socks/LICENSE
deleted file mode 100644
index 47289bb..0000000
--- a/src/code.as/core/socks/LICENSE
+++ /dev/null
@@ -1,22 +0,0 @@
-Copyright (c) 2012, Hailiang Wang. All rights reserved.
-
-Redistribution and use in source and binary forms, with or without modification,
-are permitted provided that the following conditions are met:
-
- * Redistributions of source code must retain the above copyright notice, this
-list of conditions and the following disclaimer.
-
- * Redistributions in binary form must reproduce the above copyright notice,
-this list of conditions and the following disclaimer in the documentation
-and/or other materials provided with the distribution.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
\ No newline at end of file
diff --git a/src/code.as/core/socks/README.md b/src/code.as/core/socks/README.md
deleted file mode 100644
index 869c183..0000000
--- a/src/code.as/core/socks/README.md
+++ /dev/null
@@ -1,58 +0,0 @@
-SOCKS
-=====
-
-[![GoDoc](https://godoc.org/code.as/core/socks?status.svg)](https://godoc.org/code.as/core/socks)
-
-SOCKS is a SOCKS4, SOCKS4A and SOCKS5 proxy package for Go, forked from [h12w/socks](https://github.com/h12w/socks) and patched so it's `go get`able.
-
-## Quick Start
-### Get the package
-
- go get -u "code.as/core/socks"
-
-### Import the package
-
- import "code.as/core/socks"
-
-### Create a SOCKS proxy dialing function
-
- dialSocksProxy := socks.DialSocksProxy(socks.SOCKS5, "127.0.0.1:1080")
- tr := &http.Transport{Dial: dialSocksProxy}
- httpClient := &http.Client{Transport: tr}
-
-## Example
-
-```go
-package main
-
-import (
- "fmt"
- "io/ioutil"
- "log"
- "net/http"
-
- "code.as/core/socks"
-)
-
-func main() {
- dialSocksProxy := socks.DialSocksProxy(socks.SOCKS5, "127.0.0.1:1080")
- tr := &http.Transport{Dial: dialSocksProxy}
- httpClient := &http.Client{Transport: tr}
- resp, err := httpClient.Get("http://www.google.com")
- if err != nil {
- log.Fatal(err)
- }
- defer resp.Body.Close()
- if resp.StatusCode != http.StatusOK {
- log.Fatal(resp.StatusCode)
- }
- buf, err := ioutil.ReadAll(resp.Body)
- if err != nil {
- log.Fatal(err)
- }
- fmt.Println(string(buf))
-}
-```
-
-## Alternatives
-http://godoc.org/golang.org/x/net/proxy
diff --git a/src/code.as/core/socks/socks.go b/src/code.as/core/socks/socks.go
deleted file mode 100644
index 78602ec..0000000
--- a/src/code.as/core/socks/socks.go
+++ /dev/null
@@ -1,218 +0,0 @@
-// Copyright 2012, Hailiang Wang. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-/*
-Package socks implements a SOCKS (SOCKS4, SOCKS4A and SOCKS5) proxy client.
-
-A complete example using this package:
- package main
-
- import (
- "code.as/core/socks"
- "fmt"
- "net/http"
- "io/ioutil"
- )
-
- func main() {
- dialSocksProxy := socks.DialSocksProxy(socks.SOCKS5, "127.0.0.1:1080")
- tr := &http.Transport{Dial: dialSocksProxy}
- httpClient := &http.Client{Transport: tr}
-
- bodyText, err := TestHttpsGet(httpClient, "https://h12.io/about")
- if err != nil {
- fmt.Println(err.Error())
- }
- fmt.Print(bodyText)
- }
-
- func TestHttpsGet(c *http.Client, url string) (bodyText string, err error) {
- resp, err := c.Get(url)
- if err != nil { return }
- defer resp.Body.Close()
-
- body, err := ioutil.ReadAll(resp.Body)
- if err != nil { return }
- bodyText = string(body)
- return
- }
-*/
-package socks
-
-import (
- "errors"
- "fmt"
- "net"
- "strconv"
-)
-
-// Constants to choose which version of SOCKS protocol to use.
-const (
- SOCKS4 = iota
- SOCKS4A
- SOCKS5
-)
-
-// DialSocksProxy returns the dial function to be used in http.Transport object.
-// Argument socksType should be one of SOCKS4, SOCKS4A and SOCKS5.
-// Argument proxy should be in this format "127.0.0.1:1080".
-func DialSocksProxy(socksType int, proxy string) func(string, string) (net.Conn, error) {
- if socksType == SOCKS5 {
- return func(_, targetAddr string) (conn net.Conn, err error) {
- return dialSocks5(proxy, targetAddr)
- }
- }
-
- // SOCKS4, SOCKS4A
- return func(_, targetAddr string) (conn net.Conn, err error) {
- return dialSocks4(socksType, proxy, targetAddr)
- }
-}
-
-func dialSocks5(proxy, targetAddr string) (conn net.Conn, err error) {
- // dial TCP
- conn, err = net.Dial("tcp", proxy)
- if err != nil {
- return
- }
-
- // version identifier/method selection request
- req := []byte{
- 5, // version number
- 1, // number of methods
- 0, // method 0: no authentication (only anonymous access supported for now)
- }
- resp, err := sendReceive(conn, req)
- if err != nil {
- return
- } else if len(resp) != 2 {
- err = errors.New("Server does not respond properly.")
- return
- } else if resp[0] != 5 {
- err = errors.New("Server does not support Socks 5.")
- return
- } else if resp[1] != 0 { // no auth
- err = errors.New("socks method negotiation failed.")
- return
- }
-
- // detail request
- host, port, err := splitHostPort(targetAddr)
- req = []byte{
- 5, // version number
- 1, // connect command
- 0, // reserved, must be zero
- 3, // address type, 3 means domain name
- byte(len(host)), // address length
- }
- req = append(req, []byte(host)...)
- req = append(req, []byte{
- byte(port >> 8), // higher byte of destination port
- byte(port), // lower byte of destination port (big endian)
- }...)
- resp, err = sendReceive(conn, req)
- if err != nil {
- return
- } else if len(resp) != 10 {
- err = errors.New("Server does not respond properly.")
- } else if resp[1] != 0 {
- err = errors.New("Can't complete SOCKS5 connection.")
- }
-
- return
-}
-
-func dialSocks4(socksType int, proxy, targetAddr string) (conn net.Conn, err error) {
- // dial TCP
- conn, err = net.Dial("tcp", proxy)
- if err != nil {
- return
- }
-
- // connection request
- host, port, err := splitHostPort(targetAddr)
- if err != nil {
- return
- }
- ip := net.IPv4(0, 0, 0, 1).To4()
- if socksType == SOCKS4 {
- ip, err = lookupIP(host)
- if err != nil {
- return
- }
- }
- req := []byte{
- 4, // version number
- 1, // command CONNECT
- byte(port >> 8), // higher byte of destination port
- byte(port), // lower byte of destination port (big endian)
- ip[0], ip[1], ip[2], ip[3], // special invalid IP address to indicate the host name is provided
- 0, // user id is empty, anonymous proxy only
- }
- if socksType == SOCKS4A {
- req = append(req, []byte(host+"\x00")...)
- }
-
- resp, err := sendReceive(conn, req)
- if err != nil {
- return
- } else if len(resp) != 8 {
- err = errors.New("Server does not respond properly.")
- return
- }
- switch resp[1] {
- case 90:
- // request granted
- case 91:
- err = errors.New("Socks connection request rejected or failed.")
- case 92:
- err = errors.New("Socks connection request rejected becasue SOCKS server cannot connect to identd on the client.")
- case 93:
- err = errors.New("Socks connection request rejected because the client program and identd report different user-ids.")
- default:
- err = errors.New("Socks connection request failed, unknown error.")
- }
- return
-}
-
-func sendReceive(conn net.Conn, req []byte) (resp []byte, err error) {
- _, err = conn.Write(req)
- if err != nil {
- return
- }
- resp, err = readAll(conn)
- return
-}
-
-func readAll(conn net.Conn) (resp []byte, err error) {
- resp = make([]byte, 1024)
- n, err := conn.Read(resp)
- resp = resp[:n]
- return
-}
-
-func lookupIP(host string) (ip net.IP, err error) {
- ips, err := net.LookupIP(host)
- if err != nil {
- return
- }
- if len(ips) == 0 {
- err = errors.New(fmt.Sprintf("Cannot resolve host: %s.", host))
- return
- }
- ip = ips[0].To4()
- if len(ip) != net.IPv4len {
- fmt.Println(len(ip), ip)
- err = errors.New("IPv6 is not supported by SOCKS4.")
- return
- }
- return
-}
-
-func splitHostPort(addr string) (host string, port uint16, err error) {
- host, portStr, err := net.SplitHostPort(addr)
- portInt, err := strconv.ParseUint(portStr, 10, 16)
- port = uint16(portInt)
- return
-}
diff --git a/src/code.as/core/socks/spec/SOCKS4.protocol.txt b/src/code.as/core/socks/spec/SOCKS4.protocol.txt
deleted file mode 100644
index 16483de..0000000
--- a/src/code.as/core/socks/spec/SOCKS4.protocol.txt
+++ /dev/null
@@ -1,150 +0,0 @@
- SOCKS: A protocol for TCP proxy across firewalls
-
- Ying-Da Lee
- yingda@best.com or yingda@esd.sgi.com
-
-SOCKS was originally developed by David Koblas and subsequently modified
-and extended by me to its current running version -- version 4. It is a
-protocol that relays TCP sessions at a firewall host to allow application
-users transparent access across the firewall. Because the protocol is
-independent of application protocols, it can be (and has been) used for
-many different services, such as telnet, ftp, finger, whois, gopher, WWW,
-etc. Access control can be applied at the beginning of each TCP session;
-thereafter the server simply relays the data between the client and the
-application server, incurring minimum processing overhead. Since SOCKS
-never has to know anything about the application protocol, it should also
-be easy for it to accommodate applications which use encryption to protect
-their traffic from nosey snoopers.
-
-Two operations are defined: CONNECT and BIND.
-
-1) CONNECT
-
-The client connects to the SOCKS server and sends a CONNECT request when
-it wants to establish a connection to an application server. The client
-includes in the request packet the IP address and the port number of the
-destination host, and userid, in the following format.
-
- +----+----+----+----+----+----+----+----+----+----+....+----+
- | VN | CD | DSTPORT | DSTIP | USERID |NULL|
- +----+----+----+----+----+----+----+----+----+----+....+----+
- # of bytes: 1 1 2 4 variable 1
-
-VN is the SOCKS protocol version number and should be 4. CD is the
-SOCKS command code and should be 1 for CONNECT request. NULL is a byte
-of all zero bits.
-
-The SOCKS server checks to see whether such a request should be granted
-based on any combination of source IP address, destination IP address,
-destination port number, the userid, and information it may obtain by
-consulting IDENT, cf. RFC 1413. If the request is granted, the SOCKS
-server makes a connection to the specified port of the destination host.
-A reply packet is sent to the client when this connection is established,
-or when the request is rejected or the operation fails.
-
- +----+----+----+----+----+----+----+----+
- | VN | CD | DSTPORT | DSTIP |
- +----+----+----+----+----+----+----+----+
- # of bytes: 1 1 2 4
-
-VN is the version of the reply code and should be 0. CD is the result
-code with one of the following values:
-
- 90: request granted
- 91: request rejected or failed
- 92: request rejected becasue SOCKS server cannot connect to
- identd on the client
- 93: request rejected because the client program and identd
- report different user-ids
-
-The remaining fields are ignored.
-
-The SOCKS server closes its connection immediately after notifying
-the client of a failed or rejected request. For a successful request,
-the SOCKS server gets ready to relay traffic on both directions. This
-enables the client to do I/O on its connection as if it were directly
-connected to the application server.
-
-
-2) BIND
-
-The client connects to the SOCKS server and sends a BIND request when
-it wants to prepare for an inbound connection from an application server.
-This should only happen after a primary connection to the application
-server has been established with a CONNECT. Typically, this is part of
-the sequence of actions:
-
--bind(): obtain a socket
--getsockname(): get the IP address and port number of the socket
--listen(): ready to accept call from the application server
--use the primary connection to inform the application server of
- the IP address and the port number that it should connect to.
--accept(): accept a connection from the application server
-
-The purpose of SOCKS BIND operation is to support such a sequence
-but using a socket on the SOCKS server rather than on the client.
-
-The client includes in the request packet the IP address of the
-application server, the destination port used in the primary connection,
-and the userid.
-
- +----+----+----+----+----+----+----+----+----+----+....+----+
- | VN | CD | DSTPORT | DSTIP | USERID |NULL|
- +----+----+----+----+----+----+----+----+----+----+....+----+
- # of bytes: 1 1 2 4 variable 1
-
-VN is again 4 for the SOCKS protocol version number. CD must be 2 to
-indicate BIND request.
-
-The SOCKS server uses the client information to decide whether the
-request is to be granted. The reply it sends back to the client has
-the same format as the reply for CONNECT request, i.e.,
-
- +----+----+----+----+----+----+----+----+
- | VN | CD | DSTPORT | DSTIP |
- +----+----+----+----+----+----+----+----+
- # of bytes: 1 1 2 4
-
-VN is the version of the reply code and should be 0. CD is the result
-code with one of the following values:
-
- 90: request granted
- 91: request rejected or failed
- 92: request rejected becasue SOCKS server cannot connect to
- identd on the client
- 93: request rejected because the client program and identd
- report different user-ids.
-
-However, for a granted request (CD is 90), the DSTPORT and DSTIP fields
-are meaningful. In that case, the SOCKS server obtains a socket to wait
-for an incoming connection and sends the port number and the IP address
-of that socket to the client in DSTPORT and DSTIP, respectively. If the
-DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the
-client should replace it with the IP address of the SOCKS server to which
-the cleint is connected. (This happens if the SOCKS server is not a
-multi-homed host.) In the typical scenario, these two numbers are
-made available to the application client prgram via the result of the
-subsequent getsockname() call. The application protocol must provide a
-way for these two pieces of information to be sent from the client to
-the application server so that it can initiate the connection, which
-connects it to the SOCKS server rather than directly to the application
-client as it normally would.
-
-The SOCKS server sends a second reply packet to the client when the
-anticipated connection from the application server is established.
-The SOCKS server checks the IP address of the originating host against
-the value of DSTIP specified in the client's BIND request. If a mismatch
-is found, the CD field in the second reply is set to 91 and the SOCKS
-server closes both connections. If the two match, CD in the second
-reply is set to 90 and the SOCKS server gets ready to relay the traffic
-on its two connections. From then on the client does I/O on its connection
-to the SOCKS server as if it were directly connected to the application
-server.
-
-
-
-For both CONNECT and BIND operations, the server sets a time limit
-(2 minutes in current CSTC implementation) for the establishment of its
-connection with the application server. If the connection is still not
-establiched when the time limit expires, the server closes its connection
-to the client and gives up.
diff --git a/src/code.as/core/socks/spec/rfc1928.txt b/src/code.as/core/socks/spec/rfc1928.txt
deleted file mode 100644
index 46bf46e..0000000
--- a/src/code.as/core/socks/spec/rfc1928.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Leech
-Request for Comments: 1928 Bell-Northern Research Ltd
-Category: Standards Track M. Ganis
- International Business Machines
- Y. Lee
- NEC Systems Laboratory
- R. Kuris
- Unify Corporation
- D. Koblas
- Independent Consultant
- L. Jones
- Hewlett-Packard Company
- March 1996
-
-
- SOCKS Protocol Version 5
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Acknowledgments
-
- This memo describes a protocol that is an evolution of the previous
- version of the protocol, version 4 [1]. This new protocol stems from
- active discussions and prototype implementations. The key
- contributors are: Marcus Leech: Bell-Northern Research, David Koblas:
- Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont
- Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt
- Ganis: International Business Machines.
-
-1. Introduction
-
- The use of network firewalls, systems that effectively isolate an
- organizations internal network structure from an exterior network,
- such as the INTERNET is becoming increasingly popular. These
- firewall systems typically act as application-layer gateways between
- networks, usually offering controlled TELNET, FTP, and SMTP access.
- With the emergence of more sophisticated application layer protocols
- designed to facilitate global information discovery, there exists a
- need to provide a general framework for these protocols to
- transparently and securely traverse a firewall.
-
-
-
-
-
-Leech, et al Standards Track [Page 1]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
- There exists, also, a need for strong authentication of such
- traversal in as fine-grained a manner as is practical. This
- requirement stems from the realization that client-server
- relationships emerge between the networks of various organizations,
- and that such relationships need to be controlled and often strongly
- authenticated.
-
- The protocol described here is designed to provide a framework for
- client-server applications in both the TCP and UDP domains to
- conveniently and securely use the services of a network firewall.
- The protocol is conceptually a "shim-layer" between the application
- layer and the transport layer, and as such does not provide network-
- layer gateway services, such as forwarding of ICMP messages.
-
-2. Existing practice
-
- There currently exists a protocol, SOCKS Version 4, that provides for
- unsecured firewall traversal for TCP-based client-server
- applications, including TELNET, FTP and the popular information-
- discovery protocols such as HTTP, WAIS and GOPHER.
-
- This new protocol extends the SOCKS Version 4 model to include UDP,
- and extends the framework to include provisions for generalized
- strong authentication schemes, and extends the addressing scheme to
- encompass domain-name and V6 IP addresses.
-
- The implementation of the SOCKS protocol typically involves the
- recompilation or relinking of TCP-based client applications to use
- the appropriate encapsulation routines in the SOCKS library.
-
-Note:
-
- Unless otherwise noted, the decimal numbers appearing in packet-
- format diagrams represent the length of the corresponding field, in
- octets. Where a given octet must take on a specific value, the
- syntax X'hh' is used to denote the value of the single octet in that
- field. When the word 'Variable' is used, it indicates that the
- corresponding field has a variable length defined either by an
- associated (one or two octet) length field, or by a data type field.
-
-3. Procedure for TCP-based clients
-
- When a TCP-based client wishes to establish a connection to an object
- that is reachable only via a firewall (such determination is left up
- to the implementation), it must open a TCP connection to the
- appropriate SOCKS port on the SOCKS server system. The SOCKS service
- is conventionally located on TCP port 1080. If the connection
- request succeeds, the client enters a negotiation for the
-
-
-
-Leech, et al Standards Track [Page 2]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
- authentication method to be used, authenticates with the chosen
- method, then sends a relay request. The SOCKS server evaluates the
- request, and either establishes the appropriate connection or denies
- it.
-
- Unless otherwise noted, the decimal numbers appearing in packet-
- format diagrams represent the length of the corresponding field, in
- octets. Where a given octet must take on a specific value, the
- syntax X'hh' is used to denote the value of the single octet in that
- field. When the word 'Variable' is used, it indicates that the
- corresponding field has a variable length defined either by an
- associated (one or two octet) length field, or by a data type field.
-
- The client connects to the server, and sends a version
- identifier/method selection message:
-
- +----+----------+----------+
- |VER | NMETHODS | METHODS |
- +----+----------+----------+
- | 1 | 1 | 1 to 255 |
- +----+----------+----------+
-
- The VER field is set to X'05' for this version of the protocol. The
- NMETHODS field contains the number of method identifier octets that
- appear in the METHODS field.
-
- The server selects from one of the methods given in METHODS, and
- sends a METHOD selection message:
-
- +----+--------+
- |VER | METHOD |
- +----+--------+
- | 1 | 1 |
- +----+--------+
-
- If the selected METHOD is X'FF', none of the methods listed by the
- client are acceptable, and the client MUST close the connection.
-
- The values currently defined for METHOD are:
-
- o X'00' NO AUTHENTICATION REQUIRED
- o X'01' GSSAPI
- o X'02' USERNAME/PASSWORD
- o X'03' to X'7F' IANA ASSIGNED
- o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
- o X'FF' NO ACCEPTABLE METHODS
-
- The client and server then enter a method-specific sub-negotiation.
-
-
-
-Leech, et al Standards Track [Page 3]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
- Descriptions of the method-dependent sub-negotiations appear in
- separate memos.
-
- Developers of new METHOD support for this protocol should contact
- IANA for a METHOD number. The ASSIGNED NUMBERS document should be
- referred to for a current list of METHOD numbers and their
- corresponding protocols.
-
- Compliant implementations MUST support GSSAPI and SHOULD support
- USERNAME/PASSWORD authentication methods.
-
-4. Requests
-
- Once the method-dependent subnegotiation has completed, the client
- sends the request details. If the negotiated method includes
- encapsulation for purposes of integrity checking and/or
- confidentiality, these requests MUST be encapsulated in the method-
- dependent encapsulation.
-
- The SOCKS request is formed as follows:
-
- +----+-----+-------+------+----------+----------+
- |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
- +----+-----+-------+------+----------+----------+
- | 1 | 1 | X'00' | 1 | Variable | 2 |
- +----+-----+-------+------+----------+----------+
-
- Where:
-
- o VER protocol version: X'05'
- o CMD
- o CONNECT X'01'
- o BIND X'02'
- o UDP ASSOCIATE X'03'
- o RSV RESERVED
- o ATYP address type of following address
- o IP V4 address: X'01'
- o DOMAINNAME: X'03'
- o IP V6 address: X'04'
- o DST.ADDR desired destination address
- o DST.PORT desired destination port in network octet
- order
-
- The SOCKS server will typically evaluate the request based on source
- and destination addresses, and return one or more reply messages, as
- appropriate for the request type.
-
-
-
-
-
-Leech, et al Standards Track [Page 4]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
-5. Addressing
-
- In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
- the type of address contained within the field:
-
- o X'01'
-
- the address is a version-4 IP address, with a length of 4 octets
-
- o X'03'
-
- the address field contains a fully-qualified domain name. The first
- octet of the address field contains the number of octets of name that
- follow, there is no terminating NUL octet.
-
- o X'04'
-
- the address is a version-6 IP address, with a length of 16 octets.
-
-6. Replies
-
- The SOCKS request information is sent by the client as soon as it has
- established a connection to the SOCKS server, and completed the
- authentication negotiations. The server evaluates the request, and
- returns a reply formed as follows:
-
- +----+-----+-------+------+----------+----------+
- |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
- +----+-----+-------+------+----------+----------+
- | 1 | 1 | X'00' | 1 | Variable | 2 |
- +----+-----+-------+------+----------+----------+
-
- Where:
-
- o VER protocol version: X'05'
- o REP Reply field:
- o X'00' succeeded
- o X'01' general SOCKS server failure
- o X'02' connection not allowed by ruleset
- o X'03' Network unreachable
- o X'04' Host unreachable
- o X'05' Connection refused
- o X'06' TTL expired
- o X'07' Command not supported
- o X'08' Address type not supported
- o X'09' to X'FF' unassigned
- o RSV RESERVED
- o ATYP address type of following address
-
-
-
-Leech, et al Standards Track [Page 5]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
- o IP V4 address: X'01'
- o DOMAINNAME: X'03'
- o IP V6 address: X'04'
- o BND.ADDR server bound address
- o BND.PORT server bound port in network octet order
-
- Fields marked RESERVED (RSV) must be set to X'00'.
-
- If the chosen method includes encapsulation for purposes of
- authentication, integrity and/or confidentiality, the replies are
- encapsulated in the method-dependent encapsulation.
-
-CONNECT
-
- In the reply to a CONNECT, BND.PORT contains the port number that the
- server assigned to connect to the target host, while BND.ADDR
- contains the associated IP address. The supplied BND.ADDR is often
- different from the IP address that the client uses to reach the SOCKS
- server, since such servers are often multi-homed. It is expected
- that the SOCKS server will use DST.ADDR and DST.PORT, and the
- client-side source address and port in evaluating the CONNECT
- request.
-
-BIND
-
- The BIND request is used in protocols which require the client to
- accept connections from the server. FTP is a well-known example,
- which uses the primary client-to-server connection for commands and
- status reports, but may use a server-to-client connection for
- transferring data on demand (e.g. LS, GET, PUT).
-
- It is expected that the client side of an application protocol will
- use the BIND request only to establish secondary connections after a
- primary connection is established using CONNECT. In is expected that
- a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND
- request.
-
- Two replies are sent from the SOCKS server to the client during a
- BIND operation. The first is sent after the server creates and binds
- a new socket. The BND.PORT field contains the port number that the
- SOCKS server assigned to listen for an incoming connection. The
- BND.ADDR field contains the associated IP address. The client will
- typically use these pieces of information to notify (via the primary
- or control connection) the application server of the rendezvous
- address. The second reply occurs only after the anticipated incoming
- connection succeeds or fails.
-
-
-
-
-
-Leech, et al Standards Track [Page 6]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
- In the second reply, the BND.PORT and BND.ADDR fields contain the
- address and port number of the connecting host.
-
-UDP ASSOCIATE
-
- The UDP ASSOCIATE request is used to establish an association within
- the UDP relay process to handle UDP datagrams. The DST.ADDR and
- DST.PORT fields contain the address and port that the client expects
- to use to send UDP datagrams on for the association. The server MAY
- use this information to limit access to the association. If the
- client is not in possesion of the information at the time of the UDP
- ASSOCIATE, the client MUST use a port number and address of all
- zeros.
-
- A UDP association terminates when the TCP connection that the UDP
- ASSOCIATE request arrived on terminates.
-
- In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
- fields indicate the port number/address where the client MUST send
- UDP request messages to be relayed.
-
-Reply Processing
-
- When a reply (REP value other than X'00') indicates a failure, the
- SOCKS server MUST terminate the TCP connection shortly after sending
- the reply. This must be no more than 10 seconds after detecting the
- condition that caused a failure.
-
- If the reply code (REP value of X'00') indicates a success, and the
- request was either a BIND or a CONNECT, the client may now start
- passing data. If the selected authentication method supports
- encapsulation for the purposes of integrity, authentication and/or
- confidentiality, the data are encapsulated using the method-dependent
- encapsulation. Similarly, when data arrives at the SOCKS server for
- the client, the server MUST encapsulate the data as appropriate for
- the authentication method in use.
-
-7. Procedure for UDP-based clients
-
- A UDP-based client MUST send its datagrams to the UDP relay server at
- the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
- request. If the selected authentication method provides
- encapsulation for the purposes of authenticity, integrity, and/or
- confidentiality, the datagram MUST be encapsulated using the
- appropriate encapsulation. Each UDP datagram carries a UDP request
- header with it:
-
-
-
-
-
-Leech, et al Standards Track [Page 7]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
- +----+------+------+----------+----------+----------+
- |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
- +----+------+------+----------+----------+----------+
- | 2 | 1 | 1 | Variable | 2 | Variable |
- +----+------+------+----------+----------+----------+
-
- The fields in the UDP request header are:
-
- o RSV Reserved X'0000'
- o FRAG Current fragment number
- o ATYP address type of following addresses:
- o IP V4 address: X'01'
- o DOMAINNAME: X'03'
- o IP V6 address: X'04'
- o DST.ADDR desired destination address
- o DST.PORT desired destination port
- o DATA user data
-
- When a UDP relay server decides to relay a UDP datagram, it does so
- silently, without any notification to the requesting client.
- Similarly, it will drop datagrams it cannot or will not relay. When
- a UDP relay server receives a reply datagram from a remote host, it
- MUST encapsulate that datagram using the above UDP request header,
- and any authentication-method-dependent encapsulation.
-
- The UDP relay server MUST acquire from the SOCKS server the expected
- IP address of the client that will send datagrams to the BND.PORT
- given in the reply to UDP ASSOCIATE. It MUST drop any datagrams
- arriving from any source IP address other than the one recorded for
- the particular association.
-
- The FRAG field indicates whether or not this datagram is one of a
- number of fragments. If implemented, the high-order bit indicates
- end-of-fragment sequence, while a value of X'00' indicates that this
- datagram is standalone. Values between 1 and 127 indicate the
- fragment position within a fragment sequence. Each receiver will
- have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these
- fragments. The reassembly queue must be reinitialized and the
- associated fragments abandoned whenever the REASSEMBLY TIMER expires,
- or a new datagram arrives carrying a FRAG field whose value is less
- than the highest FRAG value processed for this fragment sequence.
- The reassembly timer MUST be no less than 5 seconds. It is
- recommended that fragmentation be avoided by applications wherever
- possible.
-
- Implementation of fragmentation is optional; an implementation that
- does not support fragmentation MUST drop any datagram whose FRAG
- field is other than X'00'.
-
-
-
-Leech, et al Standards Track [Page 8]
-
-RFC 1928 SOCKS Protocol Version 5 March 1996
-
-
- The programming interface for a SOCKS-aware UDP MUST report an
- available buffer space for UDP datagrams that is smaller than the
- actual space provided by the operating system:
-
- o if ATYP is X'01' - 10+method_dependent octets smaller
- o if ATYP is X'03' - 262+method_dependent octets smaller
- o if ATYP is X'04' - 20+method_dependent octets smaller
-
-8. Security Considerations
-
- This document describes a protocol for the application-layer
- traversal of IP network firewalls. The security of such traversal is
- highly dependent on the particular authentication and encapsulation
- methods provided in a particular implementation, and selected during
- negotiation between SOCKS client and SOCKS server.
-
- Careful consideration should be given by the administrator to the
- selection of authentication methods.
-
-9. References
-
- [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
-
-Author's Address
-
- Marcus Leech
- Bell-Northern Research Ltd
- P.O. Box 3511, Stn. C,
- Ottawa, ON
- CANADA K1Y 4H7
-
- Phone: (613) 763-9145
- EMail: mleech@bnr.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leech, et al Standards Track [Page 9]
-
diff --git a/src/code.as/core/socks/spec/socks4A.protocol.txt b/src/code.as/core/socks/spec/socks4A.protocol.txt
deleted file mode 100644
index be2ff83..0000000
--- a/src/code.as/core/socks/spec/socks4A.protocol.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-SOCKS 4A: A Simple Extension to SOCKS 4 Protocol
-
- Ying-Da Lee
- yingda@best.com or yingda@esd.sgi.com
-
-Please read SOCKS4.protocol first for an description of the version 4
-protocol. This extension is intended to allow the use of SOCKS on hosts
-which are not capable of resolving all domain names.
-
-In version 4, the client sends the following packet to the SOCKS server
-to request a CONNECT or a BIND operation:
-
- +----+----+----+----+----+----+----+----+----+----+....+----+
- | VN | CD | DSTPORT | DSTIP | USERID |NULL|
- +----+----+----+----+----+----+----+----+----+----+....+----+
- # of bytes: 1 1 2 4 variable 1
-
-VN is the SOCKS protocol version number and should be 4. CD is the
-SOCKS command code and should be 1 for CONNECT or 2 for BIND. NULL
-is a byte of all zero bits.
-
-For version 4A, if the client cannot resolve the destination host's
-domain name to find its IP address, it should set the first three bytes
-of DSTIP to NULL and the last byte to a non-zero value. (This corresponds
-to IP address 0.0.0.x, with x nonzero. As decreed by IANA -- The
-Internet Assigned Numbers Authority -- such an address is inadmissible
-as a destination IP address and thus should never occur if the client
-can resolve the domain name.) Following the NULL byte terminating
-USERID, the client must sends the destination domain name and termiantes
-it with another NULL byte. This is used for both CONNECT and BIND requests.
-
-A server using protocol 4A must check the DSTIP in the request packet.
-If it represent address 0.0.0.x with nonzero x, the server must read
-in the domain name that the client sends in the packet. The server
-should resolve the domain name and make connection to the destination
-host if it can.
-
-SOCKSified sockd may pass domain names that it cannot resolve to
-the next-hop SOCKS server.
-

File Metadata

Mime Type
text/x-diff
Expires
Fri, Jan 31, 2:47 PM (9 h, 53 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
3145757

Event Timeline

musing studio · developers