Git Product home page Git Product logo

nogotofail's Introduction

nogotofail

Nogotofail is a network security testing tool designed to help developers and security researchers spot and fix weak TLS/SSL connections and sensitive cleartext traffic on devices and applications in a flexible, scalable, powerful way. It includes testing for common SSL certificate verification issues, HTTPS and TLS/SSL library bugs, SSL and STARTTLS stripping issues, cleartext issues, and more.

Design

Nogotofail is composed of an on-path network MiTM and optional clients for the devices being tested. See docs/design.md for the overview and design goals of nogotofail.

Dependencies

Nogotofail depends only on Python 2.7 and pyOpenSSL>=0.13. The MiTM is designed to work on Linux machines and the transparent traffic capture modes are Linux specific and require iptables as well.

Additionally the Linux client depends on psutil.

Getting started

See docs/getting_started.md for setup and a walkthrough of nogotofail.

Discussion

For discussion please use our nogotofail Google Group.

nogotofail's People

Contributors

bryant1410 avatar chadbrubaker avatar joshcooper avatar klyubin avatar nikai3d avatar nlewycky avatar sjlver avatar yzninja avatar zemanel avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nogotofail's Issues

Logjam vulnerability detection

See https://weakdh.org.

  • By eavesdropping on traffic, nogotofail should be able to detect whether a DH key exchange occurred over a group smaller than 1024 bit -- the current cutoff being deployed as mitigation against Logjam. The catch here is that clients which accept smaller groups will not be flagged unless the server actually uses a smaller group.
  • By MiTMing traffic with servers which support export versions of DH cipher suites, nogotofail should be able to detect clients which accept the resulting smaller DH groups.

Setuptools support

Part of some work i'm doing with the tool (Docker'ifying), on https://github.com/zemanel/nogotofail/commits/setuptools, which is based on the client_psutil branch, added proposal for setuptools support by adding a setup.py (used https://github.com/benoitc/gunicorn/blob/master/setup.py as a reference implementation):

  • defines a 0.1.0 version (from nogotofail import __version__)

  • license based on project license

  • defines packages dependencies ('pyOpenSSL >= 0.13', 'psutil')

  • some applicable classifiers

  • adds two entrypoint commands to the CLI, nogotofail-mitm and nogotofail-client-linux

    nogotofail-mitm:

      $ nogotofail-mitm -h
      usage: nogotofail-mitm [-h] [-c FILE] [-v] [-p PROBABILITY] [-d] [-a]
                             [-l LOGFILE] [-e EVENTLOGFILE] [-t TRAFFICFILE] [-q]
                             [--port PORT] [-6] [-A ATTACK [ATTACK ...]]
                             [-D ATTACK [ATTACK ...]] [--serverssl PEMFILE] [-b]
                             [--mode MODE]
    
      optional arguments:
        -h, --help            show this help message and exit
        -c FILE, --config FILE
                              Configuration file
        -v, --verbose         verbose output
        -p PROBABILITY, --probability PROBABILITY
                              probably of attacking a SSL connection
        -d, --debug           Print debug output
        -a, --all             MITM all clients
        -l LOGFILE, --logfile LOGFILE
                              Log output file
        -e EVENTLOGFILE, --eventlogfile EVENTLOGFILE
                              Event log output file
        -t TRAFFICFILE, --trafficfile TRAFFICFILE
                              Traffic output file
        -q, --quiet           Quiet output. Only prints MITM success messages
        --port PORT           Port to bind the connection to
        -6, --ipv6            Route IPv6 traffic. Requires support for ip6tables NAT redirect when in redirect mode (iptables > 1.4.17)
        -A ATTACK [ATTACK ...], --attacks ATTACK [ATTACK ...]
                              Connection attacks to run. Supported attacks are droptls, selfsigned, clientheartbleed, anonserver, dropssl, invalidhostname, earlyccs
        -D ATTACK [ATTACK ...], --data ATTACK [ATTACK ...]
                              Data attacks to run. Supported attacks are imapstarttlsstrip, httpauthdetection, imagereplace, customrequest, blockhttp, disablecdcpencryption, sslstrip, httpdetection, xmppstarttlsstrip, rawlogger, androidwebviewjsrce, xmppauthdetection, smtpstarttlsstrip, smtpauthdetection, imapauthdetection
        --serverssl PEMFILE   Run the app blame server with SSL using PEMFILE
        -b, --block           Block connections with unknown blame info
        --mode MODE           Traffic capture mode. Options are redirect, tproxy, socks
    
      Supported modes:
      redirect - Use Iptables REDIRECT to route traffic. Ipv6 support is limited in
        this mode.
      tproxy - Use iptables TPROXY/mark to route traffic
      socks - Listen as a SOCKS server to route traffic
    
      Supported attacks:
      droptls - Drops TLS connections but lets SSLv3 through
      selfsigned - Attempts to MiTM using a self-signed certificate for the requested
        domain.
      clientheartbleed - Sends a heartbleed message to the client during the SSL
        handshake
      anonserver - Attempts to MiTM connections that accept anonymous/unauthenticated
        server.
      dropssl - Drops SSL connections
      invalidhostname - Attempts to MiTM using a valid certificate for another domain.
        NOTE: requires ./trusted-cert.pem have a valid cert and private key
      earlyccs - Tests for OpenSSL early CCS vulnerability(CVE-2014-0224)
    
      Supported data handlers:
      imapstarttlsstrip - Suppress STARTTLS in IMAP
      httpauthdetection - Detect authorization headers in HTTP requests
      imagereplace - Replace responses with Content-Type of image/* with ./replace.png
      customrequest - Detect client specified regexs in requests
      blockhttp - Block HTTP traffic
      disablecdcpencryption - Disable Chrome Data Compression Proxy encryption
      sslstrip - Runs sslstrip on http traffic. Detects when sslstrip'd urls are
        visited.
      httpdetection - Detect plaintext HTTP requests and warn on them
      xmppstarttlsstrip - Suppress STARTTLS in XMPP streams
      rawlogger - Log raw traffic to the traffic log
      androidwebviewjsrce - Detect Android Webview Javascript RCE
      xmppauthdetection - Detect authentication credentials in XMPP traffic
      smtpstarttlsstrip - Suppress STARTTLS in SMTP
      smtpauthdetection - Detect authentication credentials in SMTP traffic
      imapauthdetection - Detect authentication credentials in IMAP traffic
    

    nogotofail-client-linux:

      $ nogotofail-client-linux -h
      usage: nogotofail-client-linux [-h] [-v] [-A [ATTACK [ATTACK ...]]]
                                  [-D [ATTACK [ATTACK ...]]] [-p PROBABILITY]
                                  [-q] [-S] [-l] [-c CONFIG] [-I ID] [-P ID] [-w]
                                  host port
    
      positional arguments:
      host                  Host running the blame server to connect to
      port                  Port the blame server is running on
    
      optional arguments:
      -h, --help            show this help message and exit
      -v, --verbose         verbose output
      -A [ATTACK [ATTACK ...]], --attacks [ATTACK [ATTACK ...]]
                           Connection attacks to run.
      -D [ATTACK [ATTACK ...]], --data [ATTACK [ATTACK ...]]
                           Data attacks to run.
      -p PROBABILITY, --probability PROBABILITY
                           Probability to attack connections
      -q, --quit            Quit after handshake
      -S, --nossl           Disable SSL handshake with the blame server
      -l, --list            List supported attacks and set attacks
      -c CONFIG, --config CONFIG
                           Pyblame config file location(Default to .pyblame.conf)
      -I ID, --device ID    Use ID as the device id
      -P ID, --platform ID  Use ID as the platform id
      -w, --write           Update configuration file's trusted server and device
                           id
    

I'm still in the process of understading the tool (and SSL/TLS in general) and using it successfully, so haven't tested this 100%, but can do a PR if this is interesting.

Cannot mount attack using self-signed TLS/SSL certificate after setting up on GCE

After installing the MiTM on GCE using docs/gce/setup.sh script, attacking using self-signed TLS/SSL certificate fails with:

[ERROR] argument must be an int, or have a fileno() method.
Traceback (most recent call last):
File "nogotofail/mitm/connection/server.py", line 113, in serve
cont = conn.bridge(fd)
File "nogotofail/mitm/connection/connection.py", line 241, in bridge
return self._bridge_client()
File "nogotofail/mitm/connection/connection.py", line 329, in _bridge_client
if self._check_for_ssl(client_request):
File "nogotofail/mitm/connection/connection.py", line 286, in _check_for_ssl
return self._handle_hello(client_hello)
File "nogotofail/mitm/connection/connection.py", line 316, in _handle_hello
self.connect_ssl(client_hello)
File "nogotofail/mitm/connection/connection.py", line 158, in connect_ssl
self._setup_server_connection(server_name)
File "nogotofail/mitm/connection/connection.py", line 211, in _setup_server_connection
self._do_ssl_handshake(connection)
File "nogotofail/mitm/connection/connection.py", line 230, in _do_ssl_handshake
[connection], [connection], [], remaining)
TypeError: argument must be an int, or have a fileno() method.

Adding an attack checking for certificates using SHA-1

I'd like to request addition of an an attack or feature that checks for certificates that use the SHA-1 hash algorithm.

I notice Google will soon be warning users in Chrome (v41) of certificates using SHA-1 that expire after 1 January 2016.
http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html

My suggested implementation for SHA-1 certificates is:

  • [WARNING] message for certificates expiring after 1 Jan 2016 but before 1 Jan 2017.
  • [ERROR] message for certificates expiring after 1 Jan 2017
    (to make maintenance of messages easier you could check the current date, and if it's after 1 Jan 2017 and a SHA-1 unexpired certificate is found raise [CRITICAL] message)

There shouldn't be too many certificates still using MD5, but it would be good to throw a message if one is found. Suggested implementation:

  • [CRITICAL] if any MD5 certificates are found

PS. Mozilla I believe is doing something similiar in Firefox.
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

Error: Host is unresolved

I have used android app and ran it on my device.
It's showing host is unresolved: mitm.nogotofail. How to avoid this?

Blaming a connection blocks the bridging thread

The last thing left on my bent of making everything properly unblocking on the bridging thread is the request for blame information for a connection.

Logging is dependent on the blame information so currently if it isn't present a blocking query is made to the client for connection information. This blocks the bridging thread so no other connections can make progress during this and since connections tend to be started up in batches it can cause painful linear delays for large pools.

There are two options for how to go about this:

  1. Buffer logging until we get the blame response but bridge as normal. This will work for logging but will break the ability to have handlers do things based on the blame connection without a bunch of pain.

  2. Don't do anything on the connection until the blame info comes back. This would make the connection still block on the blame information but would not block the bridging thread so other connections could still progress.

I'm leaning toward doing 2, having the blame info around is useful for handlers and the bigger issue is blocking the bridging thread and not blocking connections.

IPv6 traffic in "redirect" mode causes connection startup errors

Client attempts to connect to http://ipv6.whatismyv6.com/. nogotofail MiTM, running in redirect (not tproxy!) mode spews:

[ERROR] Socket error in connection startup from fd12:3456:789a:bcde::1000
[ERROR] [Errno 2] No such file or directory
Traceback (most recent call last):
File "nogotofail/mitm/connection/server.py", line 176, in _on_server_socket_select
self.setup_connection(client_socket)
File "nogotofail/mitm/connection/server.py", line 100, in setup_connection
if connection.start():
File "nogotofail/mitm/connection/connection.py", line 698, in start
self._get_original_dest(self.client_socket))
File "nogotofail/mitm/connection/connection.py", line 723, in _get_original_dest
dst = sock.getsockopt(socket.SOL_IP, SO_ORIGINAL_DST, 28)
File "/usr/lib64/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
error: [Errno 2] No such file or directory

Detection of the FREAK vulnerability

As a learning exercise I am considering writing a data handler to detect the FREAK vulnerability:
http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

Do you think this is worth adding to ngtf?

My understanding is for the vulnerability to exist two issues need to be present:

  1. the server needs to accept RSA export ciphers, and
  2. a vulnerability in the (mobile app) TLS library allowing secure RSA ciphers to be downgraded to export grade.

I see ngtf already checks for issue 1 (export ciphers on the server) though.

Base data handler for TLS needed

Currently we have a lot of code that looks at TLS messages looking for configuration issues or other vulns. Instead of redoing this parsing(and any needed buffering) we should have a base class for TLS checking data handlers that handles parsing and just has methods like
def on_client_tls(record):
...
def on_server_tls(record):
...

In the same style as the HttpDetection handler

nogotofail MITM fails to server traffic from Google Chrome

I followed the steps illustrated in your docs:

$ openssl req -x509 -newkey rsa:2048 -subj "/CN=mitm.nogotofail/" -nodes -keyout server.crt -out server.crt
$ python -m nogotofail.mitm -v -a --mode socks --port 8080 --serverssl server.crt
$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --proxy-server="socks5://localhost:8080" --host-resolver-rules="MAP * 0.0.0.0 , EXCLUDE localhost”

nogotofail failed with the following stack trace:

2014-11-08 11:19:21,633 [ERROR] Uncaught exception in serving thread!
Traceback (most recent call last):
  File "nogotofail/mitm/connection/server.py", line 57, in run
    self.serve()
  File "nogotofail/mitm/connection/server.py", line 98, in serve
    self.setup_connection(client_socket)
  File "nogotofail/mitm/connection/server.py", line 151, in setup_connection
    if connection.start():
  File "nogotofail/mitm/connection/connection.py", line 508, in start
    self._get_original_dest(self.client_socket))
  File "nogotofail/mitm/connection/connection.py", line 584, in _get_original_dest
    addr = request[5:5 + length]
TypeError: unsupported operand type(s) for +: 'int' and 'tuple'

How do I get nogotofail to work with Google Chrome?

Detect HTTP/2

We should make the tool detect HTTP/2 traffic as HTTP traffic. This should be fairly easy since all HTTP/2 requests are supposed to start with a fixed magic sequence.

Check for secure negotiated cipher in Server Hello request

I see Ngtf is checking the cipher suite for insecure ciphers (in Client Hello request).

It would be good to check the agreed upon cipher (in the Server Hello request) if it is secure. For example I see RC4 is still supported in Android 5.0, but it's probably not the preferred option if a cipher including this algorithm is negotiated.
https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

Also, I see 3DES, MD5 or static key ECDH is are removed from the cipher suite in Android 5.0. However if a developer has customised the client cipher suite it would be good throw a message if these are negotiated in the Server Hello request.
Hopefully throwing messages will prompt a developer to update the client and server cipher suites.
(I believe it's possible for a developer to customise the client-side cipher suite?)

Suggested implementations are:

  • Throw a [WARNING] message if a cipher containing RC4 is negotiated (in Server Hello request).
  • Throw a [ERROR] message if a cipher with 3DES, MD5 or static key ECDH is negotiated.

I hope this makes sense.

failed CalledProcessError

Hi ngtf,
Can you please help me to fix this problem.

$sudo python -m nogotofail.mitm --mode tproxy --serverssl server.crt

2017-07-24 22:11:10,976 [INFO] Starting...
2017-07-24 22:11:11,433 [ERROR] Failed to setup routing rules
Traceback (most recent call last):
File "nogotofail/mitm/util/routing.py", line 83, in enable_tproxy_rules
add_local_bypass("mangle", TPROXY_CHAIN, ipv6)
File "nogotofail/mitm/util/routing.py", line 59, in add_local_bypass
ipv6=False)
File "nogotofail/mitm/util/routing.py", line 35, in run_iptables_cmd
run_command(ipv4_bin + " " + command, ignore_failed)
File "nogotofail/mitm/util/routing.py", line 28, in run_command
raise e
CalledProcessError: Command 'iptables -t mangle -A ngtf_mangle_PREROUTING -p tcp -d 地址:127.0.0.1 -j RETURN' returned non-zero exit status 2
2017-07-24 22:23:31,104 [INFO] Blame: New client from 10.0.0.8
2017-07-24 22:23:46,183 [INFO] Blame: Client 10.0.0.8 closed connection
2017-07-24 22:23:46,220 [INFO] Blame: New client from 10.0.0.8

Migration of Android Eclipse projects to Android Studio

I see Google is ending support for Eclipse ADT at the end of this year, and Android Studio will be the supported IDE:
http://android-developers.blogspot.com/2015/06/an-update-on-eclipse-android-developer.html

At some point the Android client and test-harness app projects should be migrated to Android Studio. I migrated the 2 app projects to Android Studio in the PII fork and am happy to kick off this task (and assign the issue to me) if you want.

See migrated projects in PII fork:
https://github.com/mkenne11/nogotofail-pii/tree/dev/nogotofail/clients/android
https://github.com/mkenne11/nogotofail-pii/tree/dev/nogotofail/test/android

MITM with IOS failing

Steps performed:
1.
Ran nogotofail.mitm server using
"python -m nogotofail.mitm --mode socks --port 8080 --serverssl ../trusted-cert.pem -t traffic.log -e event.log" -A selfsigned -p 1

Made a vulnerable app in android and forced the device to use socks proxy server.(running in machine at 8080). Got the response of MITM Success.
It also worked with mac and linux machines when made insecure connection and on setting socks proxy. for instance, this was the command tested."curl --proxy socks5://my-ip:8080 https://www.google.co.in --insecure"

In similar fashion, on setting socks proxy using a pac file in iPhone and running a vulnerable app (overriding ssl verification). I got an error on client side, "CFNetwork sslhandshake failure(-108) and NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -108)". My understanding about this tool is that any requests made through socks proxy server is subjected to testing.

Note: MITM attack performed through sslsplit and dsniff tool was success and could intercept the resquest and response of IOS vulnerable app.

Error while debugging on server side:
" selfsigned](Unknown) SSL exception: (-1, 'Unexpected EOF') "

I'm not sure if it is a bug or I'm missing something.

Add checks for Frankencerts style bugs

We found some fun stuff in the frankencerts paper(http://www.cs.utexas.edu/~shmat/shmat_oak14.pdf) and should look into adding tests for similar issues here.

To really test for these kinds of issues however you'll need to control a CA trusted by the device. So far we've avoided adding tests that require device modification but it could be a useful thing to add so long as we make sure trusted CA tests are only run on clients that trust the CA controlled by nogotofail(separate from the one used for the selfsigned certs, which must not be trusted).

Linux client does not work on OSX

Execution fails due to uname parameter differences between platforms:

$ python -m nogotofail.clients.linux.pyblame -v localhost 8443
uname: illegal option -- o
usage: uname [-amnprsv]
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/Volumes/SSD2/Repositories/nogotofail/nogotofail/clients/linux/pyblame/__main__.py", line 203, in <module>
    main()
  File "/Volumes/SSD2/Repositories/nogotofail/nogotofail/clients/linux/pyblame/__main__.py", line 169, in main
    platform = subprocess.check_output(["uname", "-o", "-s", "-r", "-v"])
  File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 573, in check_output
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['uname', '-o', '-s', '-r', '-v']' returned non-zero exit status 1

platform info:

$ uname -a
Darwin victory.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

Provide example vulnerable Android app

It would be nice to provide an example app that is known to be vulnerable to a few of the things we detect so that people can easily see how the Android setup works and to verify their testing setup is working correctly.

blame.py breaks on Windows (missing socket.inet_ntop implementation)

I was able to get the blame.py client running on Windows 7 after installing the requisite psutil and pyopenssl modules, however it crashes as soon as a connection is detected. The reason is that the socket.inet_ntop function is not implemented in Python 2.x for Windows. I didn't try with 3.4 (when I believe the official implementation was released), but I found this monkey-patch that works to get the client up and running: https://pypi.python.org/pypi/win_inet_pton

Python 3?

Any plans to migrate to Python 3?

Salut je suis un nouveau je n'arrive pas

Salut je suis un nouveau développeur je vient de finir la création d'une application ANDROÏD sur l'enseignement mais je n'arrive pas à le publier sur Google PLAY aidé moi svp

Improve defaults

--all and --verbose are set on almost all invocations of nogotofail.mitm, so we should make them default.

Local interface address detection broken on Fedora 21

The local interface address detection in nogotofail/mitm/util/ip.py parses ifconfig output, assuming it conforms to the inet addr: <addr> format, but that isn't true on Fedora 21. Here is a piece of the output on my machine:

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 1019521  bytes 7437657641 (6.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1019521  bytes 7437657641 (6.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Notice the IP is not prefixed with addr:.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.