TLS/SSL Tunnel - A modern STunnel replacement written in golang

Overview

go-tunnel - Robust Quic/TLS Tunnel (Stunnel replacement)

What is it?

A supercharged Stunnel replacement written in golang. is in a sense a proxy enabling addition of network-encryption to existing clients without any source code changes.

Features

  • TLS 1.3 for client and server mode (TLS Connect or TLS Listen)
  • Quic client and server mode (Quic listen or Quic connect)
  • Optional SOCKS for connecting endpoint (SOCKS server)
  • Optional TLS client certificate (for Quic/TLS Connect)
  • SNI on the listening Quic/TLS server
  • Ratelimits - global and per-IP
  • Proxy-Protocol v1 support when connecting to downstream servers
  • YAML Configuration file
  • Access Control on per IP or subnet basis (allow/deny combination)
  • Strong ciphers and curves preferred on both client & server
  • Comes with end-to-end tests covering variety of scenarios

Note that TLS private keys need to be unencrypted; we don't support password protected private keys yet. The main reason for this is that when gotun is daemonized, it may not be possible to obtain the password in an interactive manner. Additionally, for SNI support, it may be impossible to ask for interactive password in the middle of a client connection setup.

Motivating Example

Lets assume you have a public server on proxy.example.com listening on Quic/UDP supporting SOCKS protocol for connecting to outbound destinations. For security reasons, you want to limit access to only clients that are TLS authenticated (TLS client certs).

Lets also assume that you have a laptop that wants to connect to the SOCKS server efficiently.

Using two instances of gotun, you can accomplish this:

  1. Local gotun instance on your laptop configured to accept TCP and connect using Quic to the external server proxy.example.com

  2. Server gotun instance on the external host configured to accept authenticated Quic connections and proxy via SOCKS.

  3. Configure your laptop browser to use the "local" SOCKS server.

Using Quic to connect the two gotun instances reduces the TCP/TLS overhead of every socks connection. And, TLS client certs enables strong authentication on the external server.

The picture below explains the connectivity:

example diagram

In the setup above, the laptop browser clients will treat 127.0.0.1:1080 as their "real" SOCKS server. Behind the scenes, gotun will tunnel the packets via Quic to a remote endpoint where a second gotun instance will unbundle the SOCKS protocol and connect to the final destination.

The config file shown above actually demonstrates a really secure tunnel where the server and client both use certificates to authenticate each other.

Assuming the config on "Gotunnel Laptop" is in file client.conf, and the config on "Gotunnel Server" is in server.conf, to run the above example, on host "Gotunnel-A":

gotun client.conf

And, on the public server:

gotun server.conf

The -d flag for gotun runs it in debug mode - where the logs are sent to STDOUT. It's not recommended to run a production server in debug mode (too many log messages).

Building go-tunnel

You need a reasonably new Golang toolchain (1.14+). And the go executable needs to be in your path. Then run:

make

Make essentially runs:

./build

build will build the binary gotun and places it in TARGET specific directory. e.g., for linux-amd64, the binaries will be in ./bin/linux-amd64; and OS X, it will be in ./bin/darwin-amd64 and so on.

You can cross-compile 'go-tun' by passing appropriate architecture names to the script. e.g., to build on host OS X for openbsd-amd64:

./build --arch=openbsd-amd64

You can build a statically linked executable (with no other runtime dependency):

./build -s

The script also has other options. To see them::

./build --help

Running go-tunnel

gotun takes a YAML config file as its sole command line argument. The server does not fork itself into the background. If you need that capability, explore your platform's init toolchain (e.g., start-stop-daemon).

The server can run in debug mode; e.g., on Linux x86_64:

./bin/linux-amd64/gotun -d etc/gotun.conf

In debug mode, the logs are sent to STDOUT and the debug level is set to DEBUG (i.e., verbose).

In the absence of the -d flag, the default log level is INFO or whatever is set in the config file.

Config File

The config file is a YAML v2 document. A complete, self-explanatory example is below:

# Log file; can be one of:
#  - Absolute path
#  - SYSLOG
#  - STDOUT
#  - STDERR
log: STDOUT
#log: STDOUT

# Logging level - "DEBUG", "INFO", "WARN", "ERROR"
loglevel: DEBUG

# config dir - where all non-absolute file references below will
# apply.
config-dir: /etc/gotun

# Listeners
listen:
    # Listen plain text
    -   address: 127.0.0.1:9090
        allow: [127.0.0.1/8, 11.0.1.0/24, 11.0.2.0/24]
        deny: []

        timeout:
            connect: 5
            read: 2
            write: 2

        # limit to N reqs/sec globally
        ratelimit:
            global: 2000
            per-host: 30
            cache-size: 10000

        # Connect via TLS
        connect:
            address: host.name:443
            bind: my.ip.address
            tls:
                cert: /path/to/crt
                key: /path/to/key
                # path to CA bundle that can verify the server certificate.
                # This can be a file or a directory.
                ca: /path/to/ca.crt

            # if address is a name, then servername is populated from it.
            # else, if it is an IP address, it must be set below.
            # Not setting it => no verification (InsecureSkipVerify = true)
            # servername: a.example.com

    # Listen using TLS with SNI
    -   address: 127.0.0.1:9443
        allow: [127.0.0.1/8, 11.0.1.0/24, 11.0.2.0/24]
        deny: []
        timeout:
            connect: 5
            read: 2
            write: 2

        tls:
            sni: /path/to/cert/dir

            # clientcert can be "required" or "optional" or "blank" or absent.
            # if it is required/optional, then clientca must be set to the list of
            # CAs that can verify a presented client cert.
            client-cert: required
            client-ca: /path/to/clientca.crt

        # plain connect but use proxy-protocol v1 when speaking
        # downstream
        connect:
            address: 55.66.77.88:80
            proxyprotocol: v1


    # Listen on Quic + client auth and connect to SOCKS
    -   address: 127.0.0.1:8443
        tls:
            quic: true
            cert: /path/to/crt
            key: /path/to/key
            # path to CA bundle that can verify the server certificate.
            # This can be a file or a directory.
            ca: /path/to/ca.crt

            client-cert: required
            client-ca: /path/to/clientca.crt

        connect:
            address: SOCKS

The etc/ directory has example configurations for running Quic+SOCKS on a public server and a local laptop.

Using SNI

SNI is exposed via domain specific certs & keys in the tls.certdir config block. SNI is enabled by setting tls.sni config element to true; and each hostname that is requested via SNI needs a cert and key file with the file prefix of hostname. e.g., if the client is looking for hostname "blog.mydomain.com" via SNI, then gotun will look for blog.mydomain.com.crt and blog.mydomain.com.key in the directory identified by tls.certdir. The config file above has an example for SNI configured on listen address 127.0.0.1:9443.

Generating Local Certificates

If you want client authentication and don't want the hassle of using openssl or a commercial CA for obtaining the certs, you can use certik to create an easy, opinionated local CA infrastucture. Assuming you are on a linux-amd64 platform:

$ git clone https://github.com/opencoff/certik
$ cd certik
$ ./build -s
$ ./bin/linux-amd64/certik ca.db init "client CA" 
$ ./bin/linux-amd64/certik ca.db user [email protected]
$ ./bin/linux-amd64/certik ca.db export -o ca --ca
$ ./bin/linux-amd64/certik ca.db export -o username [email protected]

Now, you have ca.crt as the CA root of trust for the Quic server to validate client certs. And, the client cert/key for [email protected] is in username.crt and username.key

You can copy and use ca.crt and user's cert/key to gotun config directory and refer to it in the config file under "client-ca" and "tls.cert", "tls.key" respectively.

Security

gotun tries to be safe by default:

  • Opinionated TLS 1.3 configuration
  • All config file references are checked for safety: e.g., any TLS certs/keys are verified to have sane permissions (NOT group/world writable)

Performance Test

Using iperf3 on two debian-linux (amd64) hosts connected via Gigabit Ethernet and gotun running on either end, the performance looks like so:

$ iperf3 -V  -c 127.0.0.1 -p 9000
iperf 3.1.3
Linux ungoliant 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64
Time: Sat, 28 Apr 2018 21:18:46 GMT
Connecting to host 127.0.0.1, port 9000
      Cookie: ungoliant.1524950326.966562.77625193
      TCP MSS: 21888 (default)
[  4] local 127.0.0.1 port 35444 connected to 127.0.0.1 port 9000
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  54.5 MBytes   457 Mbits/sec    0   2.50 MBytes
[  4]   1.00-2.00   sec  45.7 MBytes   383 Mbits/sec    0   2.50 MBytes
[  4]   2.00-3.00   sec  46.2 MBytes   388 Mbits/sec    0   2.50 MBytes
[  4]   3.00-4.00   sec  46.5 MBytes   390 Mbits/sec    0   2.50 MBytes
[  4]   4.00-5.00   sec  46.6 MBytes   391 Mbits/sec    0   2.50 MBytes
[  4]   5.00-6.00   sec  46.2 MBytes   388 Mbits/sec    0   2.50 MBytes
[  4]   6.00-7.00   sec  47.0 MBytes   394 Mbits/sec    0   2.50 MBytes
[  4]   7.00-8.00   sec  47.7 MBytes   400 Mbits/sec    0   2.50 MBytes
[  4]   8.00-9.00   sec  47.5 MBytes   398 Mbits/sec    0   2.50 MBytes
[  4]   9.00-10.00  sec  46.7 MBytes   392 Mbits/sec    0   2.50 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   475 MBytes   398 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   464 MBytes   389 Mbits/sec                  receiver
CPU Utilization: local/sender 1.8% (0.0%u/1.7%s), remote/receiver 9.0% (0.6%u/8.4%s)

Access Control Rules

Go-tunnel implements a flexible ACL by combination of allow/deny rules. The rules are evaluated in the following order:

  • If explicitly denied, then host is blocked
  • If allow list is empty, then host is allowed
  • If allow list is non-empty & host is in allow-list, then host is allowed
  • Explicit denial takes precedence over explicit allow
  • Default (fall through) policy is to deny

Example of allow/deny combinations

  1. Allow all:
   allow: []
   deny:  []
  1. Only allow specific subnets and deny everyone else:
    allow: [ 192.168.55.0/24, 172.16.10.0/24, 127.0.0.1/8 ]
    deny: []
  1. Allow all except selected subnets:
    allow: []
    deny: [ 192.168.80.0/24, 172.16.5.0/24 ]
  1. Expliclty block certain hosts and explicitly allow certain subnets and block everyone else:
    allow: [ 192.168.55.0/24, 172.16.10.0/24, 127.0.0.1/8 ]
    deny:  [ 192.168.1.1/32, 192.168.80.0/24, 172.16.5.0/24 ]

Development Notes

If you are a developer, the notes here will be useful for you:

  • The code uses go modules; so, you'll need a reasonably new go toolchain (1.10+)

  • The go-tunnel code is in ./src:

    • main.go: main() for gotun
    • server.go: Implements TCP/TLS and Quic servers; also implements the SOCKS server protocol
    • conf.go: YAML configuration file parser
    • quicdial.go: Dial outbound connections via Quic + streams
    • tcpdial.go: Dial outbound connections via TCP
    • safety.go: Safely open files/dirs referenced in config file
  • Tests: running tests: go test -v ./src Some of the tests/helpers:

    • mocked_test.go: Mock servers and clients
    • tcp_test.go: Tests for TCP/TLS to TCP/TLS
    • quic_test.go: Tests for TCP/TLS to Quic and vice versa
    • socks_test.go: Tests for socks (includes a test for the example configuration above)
    • utils_test.go: test helpers (e.g., assert())
  • We build build - a a master shell script to build the daemons; it does two very important things:

    • Puts the binary in an OS/Arch specific directory
    • Injects a git version-tag into the final binary ("linker resolved symbol")

    This script can be reused for other go projects.

  • Example config files is in the etc/gotun.conf directory.

Comments
  • Proposal: add pool of pre-established upstream TLS connections

    Proposal: add pool of pre-established upstream TLS connections

    Hello, @opencoff

    Wrapping SOCKS5 in TLS (alongside other uses of go-tunnel) is a nice idea and performs better for web surfing than conventional VPN tunnels.

    However, TLS handshake for each new TCP connection adds significant connection delay which is undesired for good browsing experience. It is possible to cancel such delay if there is some amount of already established TLS connections to upstream server.

    I've built such TLS pooling solution with Python (client) and haproxy (server), and I use it as SOCKS transport on daily basis. Today I've discovered your project and it appears to be more efficient and feature complete except TLS pooling.

    It'll be nice to have such feature in go-tunnel in order to make it an VPN alternative suitable for everyday usage.

    Unfortunately, I'm not proficient with Go and I'm not sure I can help with implementation of this feature, but I've decided to propose it. What do you think about it?

    opened by Snawoot 3
  • Resume tunnel connection

    Resume tunnel connection

    What will be my best option to resume client tunnel, if server get disconnected for a while. Actually I need to restart client side after an issue.

    <3>:2021/12/15 11:55:38.290897 [gotun-127.0.0.1:1080] quic-client: gotun:4430: can't open new stream: Application error 0x0
    <3>:2021/12/15 11:55:38.290905 [gotun-127.0.0.1:1080-127.0.0.1:54934] can't connect to gotun:4430: quic: gotun:4430: Application error 0x0
    

    Is that something I could implement easily?

    Thanks.

    opened by fegger-ducksify 2
  • Is this tool being used in production?

    Is this tool being used in production?

    I'm looking for something like this to use in our production services, so I'm wondering if there's anything running in production that's using this?

    Thanks :)

    opened by maddie 2
  • Error with golang 1.17+ / Trick to build with golang 1.16

    Error with golang 1.17+ / Trick to build with golang 1.16

    Just a tiny trick. If you're on an environment where only Go 1.17+ is available, you might encounter the following error when running the built binary:

    $ ./bin/linux-amd64/gotun
    panic: qtls.CertificateRequestInfo doesn't match
    
    goroutine 1 [running]:
    github.com/marten-seemann/qtls-go1-16.init.0()
    

    In this case, you may want to use this oneliner to build the binary in a temporary Docker container with Go 1.16:

    docker run --rm -v $(pwd):/build -w /build -u $(id -u):$(id -g) -e HOME=/build golang:1.16 make
    

    So then:

    $ ./bin/linux-amd64/gotun
    ./bin/linux-amd64/gotun: No config file!
    Usage: ./bin/linux-amd64/gotun [options] config-file
    
    opened by xi-ao 1
  • build fails with errors around ratelimit

    build fails with errors around ratelimit

    $ make
    ./build -s
    Building git:v0.4.3-0-ge29e45d76b10-dirty, linux-amd64 statically linked ..
       gotun: gotun .. 
    # github.com/opencoff/go-tunnel/gotun
    gotun/server.go:56:7: undefined: ratelimit.PerIPRateLimiter
    gotun/server.go:90:26: not enough arguments in call to ratelimit.New
    	have (uint, number)
    	want (int, int, int)
    gotun/server.go:95:13: undefined: ratelimit.NewPerIP
    gotun/server.go:402:11: p.grl.Limit undefined (type *ratelimit.RateLimiter has no field or method Limit)
    make: *** [Makefile:7: bin] Error 1
    

    this occurs on both master and with the v0.4.3 tag. I'm on Ubuntu 20.04, go version 1.14.4.

    opened by nergdron 1
  • Are other protocols in scope

    Are other protocols in scope

    Hi,

    I'm keen to build a noise protocol (with PSK) transport as a tunneling mechanism. is something along those lines in scope for this project or is it easier to keep it separate.

    there could be a need for different protocols later on as well (WireGuard for example)

    opened by mosajjal 0
  • Add support for include paths

    Add support for include paths

    One of the best features of stunnel is that it can read a directory of configuration files, allowing independent actors to drop their relevant config and have stunnel serve all needs. This is especially useful in containerized environments where it's handy to mount a per-port config file.

    opened by cornfeedhobo 0
  • Crypto Go :we are a research group to help developers build secure applications.

    Crypto Go :we are a research group to help developers build secure applications.

    Hi, we are a research group to help developers build secure applications. We designed a cryptographic misuse detector (i.e., CryptoGo) on Go language. We found your great public repository from Github, and several security issues detected by CryptoGo are shown in the following. Note that the cryptographic algorithms are categorized with two aspects: security strength and security vulnerability based on NIST Special Publication 800-57 and other public publications. Moreover, CryptoGo defined certain rules derived from the APIs of Go cryptographic library and other popular cryptographic misuse detectors. The specific security issues we found are as follows: Location: src/conf.go:335; Broken rule: SSL/TLS use insecure verification; We wish the above security issues could truly help you to build a secure application. If you have any concern or suggestion, please feel free to contact us, we are looking forward to your reply. Thanks.

    opened by 1047261438 1
  • [error] broken pipe when connecting iperf3 server

    [error] broken pipe when connecting iperf3 server

    I've been trying to test QUIC-IETF performance with your project and iperf3. I built your tunnel from source code(current master branch), and then ran the gotun client and server on different hosts, to proxy TCP connections between 2 iperf3 programs. However, the server-side then encounters a broken pipe error when writing to TCP.

    Network:

    # client iperf3
    iperf3 -c 127.0.0.1 --port 7788
    

    --->

    # client go-tunnel
    sudo ./bin/gotun -d socks5_client_adapted.yaml
    # config file: connect to go-tunnel server directly
    

    -- local ISP network -->

    # server go-tunnel
    sudo ./bin/gotun -d socks5_server_adapted.yaml
    # config file: connect to 127.0.0.1:5201 (iperf port)
    

    --->

    # server iperf3
    iperf3 -s
    

    server iperf3 logs: 图片 server go-tunnel logs:

    ./gotun: Can't enable log rotation: logger is not file backed
    config: 1 listeners
    listen on :8877 quic with tls using cert certs/srv.crt, key certs/srv.key
            connect to 127.0.0.1:5201
    <2>:2022/05/16 08:43:51.696942 [gotun] gotun - v0.7.3 [git:v0.7.3-0-gffa945b7f6ec-dirty - built on 2022-05-16T07:48.09Z] starting up (logging at DEBUG)...
    <2>:2022/05/16 08:43:51.698078 [gotun-:8877] Starting Quic server ..
    <2>:2022/05/16 08:43:51.698134 [gotun-:8877] Ratelimit: Global 20000000 req/s, Per-host: 10 req/s
    <1>:2022/05/16 08:44:18.703182 [gotun-:8877] (tcpdial.go:48) 127.0.0.1:34838 connected to 127.0.0.1:5201
    <1>:2022/05/16 08:44:18.703249 [gotun-:8877] (server.go:473) LHS 10.128.233.163:54811.0x0-10.128.227.23:8877.0x0, RHS 127.0.0.1:34838-127.0.0.1:5201
    <1>:2022/05/16 08:44:18.712512 [gotun-:8877] (tcpdial.go:48) 127.0.0.1:34840 connected to 127.0.0.1:5201
    <1>:2022/05/16 08:44:18.712565 [gotun-:8877] (server.go:473) LHS 10.128.233.163:54811.0x4-10.128.227.23:8877.0x4, RHS 127.0.0.1:34840-127.0.0.1:5201
    <1>:2022/05/16 08:44:20.708738 [gotun-:8877-10.128.227.23:8877.0x0-127.0.0.1:34838-127.0.0.1:5201] (server.go:692) 10.128.227.23:8877.0x0: nr 0, read err deadline exceeded
    <1>:2022/05/16 08:44:20.713126 [gotun-:8877-10.128.227.23:8877.0x4-127.0.0.1:34840-127.0.0.1:5201] (server.go:692) 127.0.0.1:34840: nr 0, read err read tcp 127.0.0.1:34840->127.0.0.1:5201: i/o timeout
    <1>:2022/05/16 08:44:20.714573 [gotun-:8877-10.128.227.23:8877.0x0-127.0.0.1:34838-127.0.0.1:5201] (server.go:692) 127.0.0.1:34838: nr 0, read err read tcp 127.0.0.1:34838->127.0.0.1:5201: i/o timeout
    <2>:2022/05/16 08:44:20.714661 [gotun-:8877-10.128.227.23:8877.0x0-127.0.0.1:34838-127.0.0.1:5201] 10.128.233.163:54811.0x0-10.128.227.23:8877.0x0: rd 142, wr 4; 127.0.0.1:34838-127.0.0.1:5201: rd 4, wr 142
    <1>:2022/05/16 08:44:20.715817 [gotun-:8877-10.128.227.23:8877.0x4-127.0.0.1:34840-127.0.0.1:5201] (server.go:713) 127.0.0.1:5201: Write Err write tcp 127.0.0.1:34840->127.0.0.1:5201: write: broken pipe
    <2>:2022/05/16 08:44:20.715898 [gotun-:8877-10.128.227.23:8877.0x4-127.0.0.1:34840-127.0.0.1:5201] 10.128.233.163:54811.0x4-10.128.227.23:8877.0x4: rd 16167005, wr 0; 127.0.0.1:34840-127.0.0.1:5201: rd 0, wr 16161365
    
    opened by ClSlaid 3
  • Support UDP over TLS1.3 tunnel?

    Support UDP over TLS1.3 tunnel?

    We know go-tunnel could connect by Quic/TLS tunnel. But we aslo find udp could be limited by QoS by network Carrier. so do you any plan support udp over tls?

    It is very useful to VPN based on udp, such as wireguard.

    I search find this project, but the code is very bad

    opened by 0neday 2
Releases(v0.6.0)
  • v0.6.0(Jul 4, 2020)

    Major feature update:

    • Support for Quic for inbound and outbound connections
    • Support for SOCKS for outbound connections
    • full end-to-end test covering many scenarios
    Source code(tar.gz)
    Source code(zip)
Owner
Sudhi Herle
Sudhi Herle
Golang Library for automatic LetsEncrypt SSL Certificates

Obtains certificates automatically, and manages renewal and hot reload for your Golang application. It uses the LEGO Library to perform ACME challenges, and the mkcert utility to generate self-signed trusted certificates for local development.

Foomo web framework 181 Nov 10, 2022
gdn is a Go module to get domain name from SSL certificates given an IP address

Get Domain Name gdn is a Go module to get domain name from SSL certificates given an IP address Installation Instructions From Source gdn requires go1

Sai Krishna Kothapalli 16 Nov 9, 2022
Certificate monitoring utility for watching tls certificates and reporting the result as metrics.

cert-checker cert-checker is a certificate monitoring utility for watching tls certificates. These checks get exposed as Prometheus metrics to be view

Frederik Mogensen 86 Nov 1, 2022
Automatic HTTPS for any Go program: fully-managed TLS certificate issuance and renewal

Easy and Powerful TLS Automation The same library used by the Caddy Web Server Caddy's automagic TLS features—now for your own Go programs—in one powe

Caddy 4.3k Nov 28, 2022
For whatever reason you want to transfer TLS certificates in kubernetes to Qiniu CDN

Qiniu Certificate Sync For whatever reason you want to transfer TLS certificates in kubernetes to Qiniu CDN This app will upload provided TLS secrets

null 2 Oct 21, 2021
Crypto-project - Personal project for learning TLS

crypto-project My personal attempt to implement this cipher suite using the Go l

Matheus Pimenta 0 Feb 14, 2022
A drop-in replacement to any Writer type, which also calculates a hash using the provided hash type.

writehasher A drop-in replacement to any Writer type, which also calculates a hash using the provided hash type. Example package main import ( "fmt"

Max 0 Jan 10, 2022
a modern crypto messaging format

saltpack a modern crypto messaging format https://saltpack.org/ saltpack is a streamlined, modern solution, designed with simplicity in mind. It is ea

Keybase 943 Nov 27, 2022
A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

Filippo Valsorda 12.1k Nov 24, 2022
A Binance Chain vanity address generator written in golang.

VaniBNB A Binance Chain vanity address generator written in golang. For example address ending with 0xkat Raw https://github.com/makevoid/vanieth http

undefi.org 8 Sep 9, 2022
Stackledger: a new blockchain written in golang

StackLedger Stackledger is a new blockchain. It is written in golang and uses a novel networking stack built from two primitives: channels and extensi

null 1 Feb 21, 2022
A system written in Golang to help ops team to automate the process of mapping Vault groups to LDAP Groups.

A system written in Golang to help ops team to automate the process of mapping Vault groups to LDAP Groups. This utility automatically adds LDAP Groups' members to the corresponding Vault Groups.

Rahul Indra 0 Nov 12, 2021
goBlockChain is a version of the classic blockChain with POW algorithms written in golang.

goBlockChain is a version of the classic blockChain with POW algorithms written in golang. May come in handy when learning about this technology.

Alexandr Primak 1 Oct 31, 2021
Ethconvert: Ethereum unit converter written in golang

ethconvert Ethereum unit converter written in go. Install go get github.com/jon4

Jonah 1 Jul 24, 2022
Full bitcoin solution written in Go (golang)

About Gocoin Gocoin is a full Bitcoin solution written in Go language (golang). The software architecture is focused on maximum performance of the nod

Piotr Narewski 899 Nov 19, 2022
A third-party wrapper for CryptAPI written in golang.

A third-party wrapper for CryptAPI written in golang.

Chris 1 Jan 31, 2022
A simple and lightweight encrypted password manager written in Go.

Osiris Password Manager A simple and lightweight encrypted password manager written in Go

null 32 Jun 16, 2022
A full node Bitcoin (BSV) implementation written in Go

bsvd bsvd is a full node Bitcoin (BSV) implementation written in Go (golang). This project is a port of the bchd codebase to Bitcoin (BSV). It provide

null 41 Feb 7, 2022